An upgrading method and device of an in-vehicle controller and a vehicle

Abstract

The application relates to an upgrading method and device of a vehicle-mounted controller and a vehicle, to solve the problem that in the prior art, a synchronous blocking type upgrading method causes an upgrading task and real-time business of the vehicle to mutually occupy communication resources and computing resources, and the background non-susceptible upgrading cannot be realized while ensuring stable operation of the vehicle. The method comprises the following steps: determining a running condition grade currently reached by the vehicle according to multi-dimensional real-time running state information of the vehicle; adjusting a transmission data amount and a transmission interval of upgrading package data according to the running condition grade; issuing the upgrading package data to a target controller through a communication bus according to the adjusted transmission data amount and transmission interval, so that the upgrading data flow and the normal business data flow of the vehicle are time-division and peak-shifting transmitted on the communication bus; creating an upgrading task corresponding to the upgrading package data; configuring an execution priority of the upgrading task according to the running condition grade; and controlling the target controller to perform upgrading based on the upgrading package data according to the execution priority of the upgrading task.

Description

Technical Field

[0001] This application relates to the field of vehicle-mounted OTA upgrades, specifically to an upgrade method, device, and vehicle for a vehicle-mounted controller. Background Technology

[0002] Traditional vehicle upgrades employ a UDS protocol stack combined with a single-partition upgrade mode. However, this mode requires a forced switch to a programming session during the upgrade, suspending normal device control and bus communication functions, resulting in a complete shutdown and blocking state, making online updates impossible while the device is running. Furthermore, traditional UDS uses a synchronous centralized transmission mechanism, monopolizing bus resources during the flashing process, limiting transmission speed and making it susceptible to interference. In the event of power outages, communication interruptions, or other abnormal situations, program corruption and device downtime are highly likely, lacking a reliable upgrade protection mechanism. With the widespread adoption of software-defined vehicles and remote OTA technology, the firmware iteration frequency of intelligent electronic control units such as BMS and domain controllers has increased significantly. The existing UDS shutdown flashing mode can no longer meet the application requirements of on-the-go online upgrades, silent background maintenance, and high security and fault tolerance.

[0003] Existing synchronous blocking upgrade methods lead to competition for communication and computing resources between upgrade tasks and real-time vehicle services, making it impossible to achieve seamless background upgrades while ensuring stable real-time vehicle operation. Therefore, the field of vehicle upgrades is now introducing seamless upgrade technology. However, current seamless upgrades for in-vehicle and embedded devices mostly employ overall synchronous transmission and centralized task scheduling modes, still lacking timing planning and asynchronous coordination mechanisms, thus failing to solve the aforementioned core problems. Batch distribution of upgrade data packets easily consumes bus bandwidth, causing lag in normal driving control, vehicle-to-everything (V2X) interactions, and other real-time services; upgrade data and service data compete for communication resources, making dynamic allocation of transmission time slots impossible. At the task scheduling level, synchronous waiting scheduling requires each module to complete its upgrade before starting the next; simultaneous upgrades of multiple controllers easily lead to conflicts in computing and storage resources, resulting in long upgrade times and making it difficult to achieve seamless background upgrades. Furthermore, traditional solutions do not differentiate upgrade task priorities, making it easy for sudden service interruptions to be blocked by the upgrade process, failing to balance upgrade efficiency and real-time device stability. Summary of the Invention

[0004] This application provides an upgrade method, device, and vehicle for an on-board controller, to solve the problem that the synchronous blocking upgrade method in the prior art causes the upgrade task and the vehicle's real-time services to compete for communication and computing resources, making it impossible to achieve seamless background upgrades while ensuring the vehicle's real-time stable operation.

[0005] The technical solution of this invention is as follows:

[0006] Firstly, this application provides a method for upgrading an on-board controller, comprising:

[0007] Obtain multi-dimensional real-time operating status information of vehicles;

[0008] Based on the multi-dimensional real-time operating status information, the current operating condition level of the vehicle is determined;

[0009] Adjust the amount of data transmitted and the transmission interval of the upgrade package data according to the aforementioned operating condition level;

[0010] According to the adjusted data transmission volume and transmission interval, the upgrade package data is sent to the target controller through the communication bus, so that the upgrade data stream and the normal vehicle business data stream are transmitted on the communication bus in a time-sharing and staggered manner.

[0011] Create an upgrade task corresponding to the upgrade package data;

[0012] Configure the execution priority of the upgrade task according to the aforementioned operating condition level;

[0013] Based on the execution priority of the upgrade task, the target controller is controlled to perform an upgrade based on the upgrade package data.

[0014] By acquiring multi-dimensional operational status information of the vehicle in real time and determining the current operating condition level accordingly, the data transmission volume and interval of the upgrade package are dynamically adjusted. When the vehicle is operating under high load, the data volume of a single transmission is reduced, and the transmission interval is lengthened. This prevents the upgrade data stream from consuming bus bandwidth in bursts of large traffic, instead transmitting it as sparse small data packets interspersed in the gaps between the vehicle's normal business data stream. This time-sharing and peak-shifting transmission mechanism fundamentally eliminates the resource competition between upgrade data and business data on the communication bus, ensuring that the vehicle can maintain normal driving control and vehicle-to-everything (V2X) interaction functions during the upgrade process, without experiencing service interruptions or delays caused by the bus being filled with upgrade data.

[0015] Based on the vehicle's current operating conditions, upgrade tasks are configured with different execution priorities. Under high load conditions, upgrade tasks are placed in the background and run with low priority, while under low load conditions, their priority can be appropriately increased to speed up the upgrade process. More importantly, when high-priority real-time vehicle services need to run, the upgrade task is immediately paused and the interrupt context is saved. After the real-time service is completed, the upgrade task resumes execution from the breakpoint through an asynchronous event. This asynchronous scheduling mechanism ensures that upgrade tasks do not block the execution of real-time vehicle services. Even if safety-critical services such as power control and fault diagnosis suddenly occur during the upgrade process, they can be responded to in milliseconds, and the computing resource requirements of these services can be prioritized.

[0016] In summary, time-sharing and peak-shifting transmission at the communication layer resolves the bandwidth contention between upgrade data streams and business data streams, while asynchronous priority scheduling at the computing layer resolves the resource contention between upgrade tasks and real-time business tasks. The synergy of these two approaches ensures that the entire upgrade process is completely seamless for the user. Vehicles can still be driven, controlled, and interacted with normally during the upgrade, guaranteeing driving safety and enabling silent background upgrades—truly achieving upgrades without disrupting traffic and uninterrupted business operations.

[0017] In some possible embodiments, the multi-dimensional real-time operating status information includes: controller hardware resource occupancy status, vehicle business task operating status, communication link status, and vehicle driving condition status. The step of determining the current operating condition level of the vehicle based on the multi-dimensional real-time operating status information includes:

[0018] The controller hardware resource occupancy status, the vehicle business task operation status, the communication link status, and the vehicle driving condition status are respectively quantified to generate sub-item scores for each dimension;

[0019] The scores of each sub-item are weighted and summed according to preset weights to obtain the comprehensive load score.

[0020] Based on the comprehensive load score, the current operating condition level of the vehicle is determined.

[0021] The status information of each dimension has different physical meanings and dimensions. For example, hardware resource utilization is expressed as a percentage, business operation status is expressed as task type and quantity, communication link status is expressed as bus load rate, and driving conditions are expressed as vehicle speed and gear. These different types of information cannot be directly evaluated comprehensively. Feature quantization maps them to a unified scoring scale, enabling information from each dimension to be compared and integrated under the same standard. The introduction of weighted summation allows the contribution of each dimension in the comprehensive evaluation to be configured differently according to actual safety needs. Dimensions related to driving safety are given higher weights, thereby ensuring that the comprehensive load score can truly reflect the current operating pressure and safety risk level of the vehicle, providing an accurate and reliable decision-making basis for subsequent transmission scheduling and task scheduling.

[0022] In some possible embodiments, the step of determining the current operating condition level of the vehicle based on the comprehensive load score includes:

[0023] When the comprehensive load score belongs to the first preset score range, the current operating condition level of the vehicle is determined to be a high load condition, the corresponding data transmission volume is the first data volume threshold, and the corresponding transmission interval is the first time interval.

[0024] When the comprehensive load score belongs to the second preset score range, the current operating condition level of the vehicle is determined to be the normal load condition, the corresponding data transmission volume is the second data volume threshold, and the corresponding transmission interval is the second time interval.

[0025] When the comprehensive load score belongs to the third preset score range, the current operating condition level of the vehicle is determined to be low load idle condition, the corresponding data transmission amount is the third data volume threshold, and the corresponding transmission interval is the third time interval.

[0026] Wherein, the first data volume threshold is less than the second data volume threshold, and the second data volume threshold is less than the third data volume threshold; the first time interval is greater than the second time interval, and the second time interval is greater than the third time interval.

[0027] By comparing the comprehensive load score with the preset score range, the complex real-time operating state of the vehicle is mapped into a finite number of discrete and distinguishable operating condition levels, each corresponding to a specific set of transmission parameter configurations. The comprehensive load score is a continuous value; directly mapping it to specific transmission parameters would result in an overly granular control strategy that is difficult to execute stably. Discretizing it into a finite number of operating condition levels using the preset score range makes the transmission parameter adjustment strategy clear and controllable. Simultaneously, the first data volume threshold is less than the second data volume threshold and less than the third data volume threshold, and the first time interval is greater than the second time interval and greater than the third time interval. This means that the high-load operating condition corresponds to the minimum transmission data volume and the maximum transmission interval, while the low-load idle operating condition corresponds to the maximum transmission data volume and the minimum transmission interval. This configuration pattern is positively correlated with the vehicle's available communication resources under different operating conditions: under high load conditions, the bus is occupied by a large amount of service data, and available communication resources are scarce. Therefore, transmission must be carried out with the minimum data volume and the longest interval, occupying only a small amount of communication resources to ensure priority transmission of service data; under low load and idle conditions, the bus is relatively idle, and available communication resources are abundant. Therefore, transmission can be carried out with the maximum data volume and the shortest interval, making full use of idle bandwidth resources to accelerate the upgrade process. This mechanism ensures that the transmission behavior of the upgrade data stream always matches the real-time operating status of the vehicle, neither increasing the communication burden when the vehicle is busy nor wasting upgrade opportunities when the vehicle is idle.

[0028] In some possible embodiments, the step of adjusting the amount of data transmitted and the transmission interval of the upgrade package data according to the operating condition level includes:

[0029] When the operating condition level is high load condition, the amount of data transmitted is adjusted to a first data amount threshold, and the transmission interval is adjusted to a first time interval;

[0030] When the operating condition level is normal load condition, the amount of data transmitted is adjusted to the second data amount threshold, and the transmission interval is adjusted to the second time interval;

[0031] When the operating condition level is low load idle condition, the amount of data transmitted is adjusted to the third data amount threshold, and the transmission interval is adjusted to the third time interval;

[0032] The first data volume threshold is less than the second data volume threshold, and the second data volume threshold is less than the third data volume threshold; the first time interval is greater than the second time interval, and the second time interval is greater than the third time interval.

[0033] By differentiating the transmission data volume and interval according to the operating condition level, the download behavior of the upgrade package data is dynamically adapted to the vehicle's current real-time operating status. Different operating condition levels reflect different levels of vehicle workload and communication resource occupancy. High-load operating conditions correspond to the minimum transmission data volume and the maximum transmission interval, while low-load idle operating conditions correspond to the maximum transmission data volume and the minimum transmission interval. This adaptation relationship ensures that the bus occupancy rate of the upgrade data stream automatically decreases as the vehicle load increases and automatically increases as the vehicle load decreases, forming an automatic avoidance mechanism between upgrade transmission and vehicle services. This ensures that upgrade traffic actively contracts to free up communication resources when vehicle services are busy, and actively expands to accelerate the upgrade process when vehicle services are idle.

[0034] In some possible embodiments, the upgrade package data adopts a splittable data structure, which is used to split the upgrade package data into multiple underlying data units, each of which is transmitted and verified independently; the amount of data transmitted is the amount of data of the underlying data unit in a single transmission.

[0035] By splitting the upgrade package data into multiple independent transmission and verification underlying data units, the upgrade package data is no longer sent as a single, indivisible unit all at once. Instead, it is sent in batches as multiple underlying data units. Since the amount of transmitted data is defined as the amount of data in a single underlying data unit, adjusting the amount of transmitted data under different operating conditions essentially means adjusting the size of the underlying data unit contained in each transmission. Under high load conditions, the amount of data in a single underlying data unit is reduced, resulting in shorter bus time and less disruption to business data. Under low load and idle conditions, the amount of data in a single underlying data unit is increased, allowing each transmission to carry more upgrade data, reducing the number of transmission interactions, and thus improving transmission efficiency. Because the upgrade package data uses a splittable data structure, the transmission of upgrade data has the ability to adapt to different operating conditions with fine granularity, providing a data-level foundation for time-sharing and peak-shifting transmission. Meanwhile, each underlying data unit independently carries verification information. If any underlying data unit is damaged or lost during transmission, only that unit needs to be retransmitted instead of the entire upgrade package, which reduces the retransmission overhead in abnormal situations and improves the efficiency and robustness of upgrade transmission.

[0036] In some possible embodiments, the step of configuring the execution priority of the upgrade task according to the operating condition level includes:

[0037] When the operating condition level is high load condition, the upgrade task is configured with a priority lower than the vehicle real-time service and lower than the regular service, and the upgrade task is assigned to the periodic task queue with the longest time period for execution.

[0038] When the operating condition level is normal load condition, the upgrade task is configured with a priority lower than the vehicle real-time service but higher than or equal to the normal service, and the upgrade task and the normal service are assigned to the periodic task queue with the same time period for execution.

[0039] When the operating condition level is low load idle condition, the upgrade task is configured with a priority lower than the vehicle real-time service but higher than the regular service. The upgrade task is assigned to the shortest time period period task queue for execution, and the regular service is assigned to the intermediate time period period task queue for execution. The intermediate time period is between the shortest time period and the longest time period.

[0040] The real-time vehicle services refer to services involving vehicle safety control, while the routine services refer to non-core services that do not involve vehicle safety control.

[0041] By dividing vehicle tasks into three levels—real-time vehicle services, routine services, and upgrade tasks—and dynamically adjusting the priority of upgrade tasks relative to the other two types of services based on the operating condition, vehicle computing resources are rationally allocated under different operating scenarios. Real-time vehicle services involve driving safety and have the highest, unchallengeable priority under any operating condition, ensuring that safety-related tasks always receive priority computing resources. Routine services do not involve driving safety and can be surpassed by upgrade tasks under high load and also under low load, exhibiting a flexible and variable intermediate priority. As a background maintenance task, the priority of upgrade tasks changes with the operating condition: under high load conditions, it drops to after all tasks to avoid interfering with any vehicle services; under low load and idle conditions, it rises to before routine services to accelerate the upgrade process. This mechanism minimizes the computing resource consumption of upgrade tasks under high load conditions, ensuring that routine and real-time services are unaffected by the upgrade process; under low load and idle conditions, upgrade tasks receive more computing resources to shorten upgrade time. Especially when the vehicle is in a safety-sensitive scenario such as driving, the upgrade task is placed with the lowest priority. The upgrade process will not have any perceptible impact on the response time of safety-critical businesses such as power control and fault diagnosis, thus ensuring the coexistence of driving safety and backend upgrades.

[0042] In some possible embodiments, the step of controlling the target controller to perform an upgrade based on the upgrade package data according to the execution priority of the upgrade task includes:

[0043] According to the execution priority of the upgrade task, the target controller is controlled to write the upgrade package data to its inactive storage partition;

[0044] During the writing of the upgrade package data, the system listens for high-priority trigger events of the vehicle's real-time services.

[0045] When a trigger event for the vehicle's real-time service is detected, the target controller is controlled to pause the current write operation and record the location information of the written data as an interrupt context.

[0046] After pausing the write operation, control the target controller to switch to the vehicle's real-time service execution.

[0047] Once the real-time vehicle service is completed, an asynchronous event is generated to notify the upgrade task to resume execution.

[0048] Based on the asynchronous event, the target controller is controlled to continue writing the upgrade package data from the data position where writing was paused, according to the interrupt context, until the burning of the inactive storage partition is completed.

[0049] Through the above steps, the write operation of the upgrade task is no longer a one-time, uninterrupted continuous process, but is divided into multiple pauseable and resumable segments. During the write process, continuous monitoring of high-priority vehicle real-time service trigger events is equivalent to setting a real-time service priority detection point in the upgrade process, ensuring that the upgrade operation does not block the response to safety-critical services. When a vehicle real-time service is detected to be running, the write operation is immediately paused and the interruption position is recorded. Subsequently, computing resources are switched to the real-time service, ensuring the timely execution of safety-critical tasks. After the real-time service is completed, the upgrade task is resumed via an asynchronous event, rather than continuously polling to check if the real-time service has ended. This avoids the upgrade task consuming processor resources for invalid queries during the waiting period, ensuring that the upgrade task does not consume computing resources while waiting for recovery, and is only reactivated upon receiving an asynchronous event. Crucially, the recording of the interrupt context and the recovery based on the interrupt context enable the upgrade write to resume from where it left off. The write progress before the pause is completely saved, and upon resumption, the write continues directly from the paused position. This avoids restarting the entire write process and prevents the loss of already written data, ensuring that the upgrade task can still be completed efficiently even after multiple interruptions by real-time services.

[0050] Secondly, this application provides an upgrade device for an on-board controller, comprising:

[0051] The acquisition module is used to acquire multi-dimensional real-time operating status information of the vehicle.

[0052] The operating condition level determination module is used to determine the current operating condition level of the vehicle based on the multi-dimensional real-time operating status information.

[0053] The adjustment module is used to adjust the amount of data transmitted and the transmission interval of the upgrade package data according to the operating condition level.

[0054] The distribution module is used to distribute the upgrade package data to the target controller through the communication bus according to the adjusted transmission data volume and transmission interval, so that the upgrade data stream and the normal vehicle business data stream are transmitted in a time-sharing and staggered manner on the communication bus.

[0055] A creation module is used to create an upgrade task corresponding to the upgrade package data;

[0056] The priority configuration module is used to configure the execution priority of the upgrade task according to the operating condition level;

[0057] The control module is used to control the target controller to perform an upgrade based on the upgrade package data according to the execution priority of the upgrade task.

[0058] Optionally, the adjustment module includes:

[0059] The first adjustment unit is used to adjust the amount of transmitted data to a first data amount threshold and the transmission interval to a first time interval when the operating condition level is a high load condition.

[0060] The second adjustment unit is used to adjust the amount of transmitted data to a second data amount threshold and the transmission interval to a second time interval when the operating condition level is a normal load condition.

[0061] The third adjustment unit is used to adjust the amount of transmitted data to a third data amount threshold and the transmission interval to a third time interval when the operating condition level is a low load idle condition.

[0062] The first data volume threshold is less than the second data volume threshold, and the second data volume threshold is less than the third data volume threshold; the first time interval is greater than the second time interval, and the second time interval is greater than the third time interval.

[0063] Optionally, the priority configuration module includes:

[0064] The first priority configuration unit is used to configure the upgrade task to a priority lower than the vehicle real-time service and lower than the regular service when the operating condition level is high load condition, and the upgrade task is assigned to the periodic task queue with the longest time period for execution.

[0065] The second priority configuration unit is used to configure the upgrade task to a priority lower than the vehicle real-time service but higher than or equal to the regular service when the operating condition level is a normal load condition. The upgrade task and the regular service are assigned to the periodic task queue with the same time period for execution.

[0066] The third priority configuration unit is used to configure the upgrade task as having a priority lower than the vehicle real-time service but higher than the regular service when the operating condition level is low load idle condition. The upgrade task is assigned to the shortest time period period task queue for execution, and the regular service is assigned to the intermediate time period period task queue for execution. The intermediate time period is between the shortest time period and the longest time period.

[0067] The real-time vehicle services refer to services involving vehicle safety control, while the routine services refer to non-core services that do not involve vehicle safety control.

[0068] Optionally, the control module includes:

[0069] The first control unit is configured to control the target controller to write the upgrade package data into its inactive storage partition according to the execution priority of the upgrade task.

[0070] The monitoring unit is used to monitor high-priority triggering events of the vehicle's real-time services during the writing process of the upgrade package data.

[0071] The interrupt unit is used to control the target controller to pause the current write operation and record the location information of the written data as the interrupt context when a trigger event of the vehicle's real-time service is detected.

[0072] The second control unit is used to control the target controller to switch to the real-time business execution of the vehicle after the writing is paused;

[0073] An asynchronous event generation unit is used to generate an asynchronous event to notify the upgrade task to resume execution after the real-time service of the vehicle has been completed.

[0074] The third control unit is used to control the target controller to continue writing the upgrade package data from the data position at the time of the paused writing, according to the interrupt context, based on the asynchronous event, until the burning of the inactive storage partition is completed.

[0075] Thirdly, this application provides a vehicle including the aforementioned upgrade device for the vehicle controller. Attached Figure Description

[0076] Figure 1 This is a flowchart illustrating the method of an embodiment of this application;

[0077] Figure 2 This is a structural diagram of the upgrade package data in the embodiments of this application;

[0078] Figure 3 This is a schematic diagram illustrating the multi-dimensional comprehensive vehicle status assessment in an embodiment of this application;

[0079] Figure 4 This is a schematic diagram illustrating task priority allocation and asynchronous triggering in an embodiment of this application;

[0080] Figure 5 This is a schematic diagram of the device in the embodiments of this application. Detailed Implementation

[0081] Reference Figure 1 This application provides an upgrade method for an on-board controller, including:

[0082] S101, acquires multi-dimensional real-time operating status information of the vehicle;

[0083] S102, Based on the multi-dimensional real-time operating status information, determine the current operating condition level of the vehicle;

[0084] S103, Adjust the amount of data transmitted and the transmission interval of the upgrade package data according to the operating condition level;

[0085] S104, according to the adjusted transmission data volume and transmission interval, the upgrade package data is sent to the target controller through the communication bus, so that the upgrade data stream and the vehicle normal business data stream are transmitted on the communication bus in a time-sharing and staggered manner.

[0086] S105, Create an upgrade task corresponding to the upgrade package data;

[0087] S106, Configure the execution priority of the upgrade task according to the operating condition level;

[0088] S107, Based on the execution priority of the upgrade task, control the target controller to perform an upgrade based on the upgrade package data.

[0089] In step S101, real-time operating status information across multiple dimensions is periodically collected via diagnostic services or the vehicle communication bus. The collection period can be set according to actual application requirements, for example, to 100 milliseconds.

[0090] Multi-dimensional real-time operational status information can include one or more of the following: controller hardware resource occupancy status, vehicle business task operation status, communication link status, and vehicle driving condition status. Controller hardware resource occupancy status reflects the current hardware load pressure of the target controller and can be obtained by reading parameters such as CPU utilization, memory usage, or Flash write / erase status. Vehicle business task operation status reflects the execution status of various vehicle functions and can be obtained through the task scheduler or business status monitoring module, showing the type and number of currently running tasks, such as whether power control tasks, battery management tasks, and fault diagnosis tasks are active. Communication link status reflects the current occupancy of the vehicle communication bus and can be obtained through bus analysis or communication protocol stack parameters such as bus load rate, communication error rate, or data transmission latency. Vehicle driving condition status reflects the current operating scenario of the vehicle and can be obtained through vehicle speed sensors, gear position sensors, or charging status signals, showing information such as vehicle speed, gear position, or whether it is charging.

[0091] Step S102 includes: when determining the current operating condition level of the vehicle based on multi-dimensional real-time operating status information, firstly, the multi-dimensional real-time operating status information is quantified to generate sub-item scores corresponding to each dimension, then the sub-item scores are weighted and summed according to preset weights to calculate the comprehensive load score, and finally the current operating condition level of the vehicle is determined based on the comprehensive load score.

[0092] Reference Figure 3Each dimension of status information has different physical meanings and dimensions. For example, hardware resource occupancy status is represented by CPU utilization percentage, communication link status by bus load percentage, vehicle business task operation status by the type and quantity of currently running tasks, and vehicle driving condition status by speed and gear. This raw data cannot be directly used for numerical calculations. Therefore, it is necessary to normalize and map the raw data for each dimension, converting it into a dimensionless sub-item score within the range of 0 to 100. The value of the sub-item score represents the current load or risk level of that dimension; the higher the value, the heavier the load or the higher the risk. For example, for CPU utilization, when the utilization rate is in the range of 0 to 30%, it can be mapped to a low score range of 0 to 30, indicating that the hardware resources are idle; when the utilization rate is in the range of 30% to 70%, it can be mapped to a medium score range of 30 to 70, indicating that the hardware resources are under normal load; when the utilization rate exceeds 70%, it can be mapped to a high score range of 70 to 100, indicating that the hardware resources are under heavy load. For dimensions such as bus load rate, number and type of activated business tasks, and vehicle speed, the conversion from raw values ​​to sub-item scores is completed according to their respective preset mapping rules. The preset mapping rules for each dimension can be pre-calibrated based on vehicle engineering experience, making the sub-item scores of each dimension comparable under the same scoring scale.

[0093] After quantifying the features of each dimension and generating sub-item scores, the sub-item scores corresponding to the controller hardware resource occupancy status, vehicle business task operation status, communication link status, and vehicle driving condition status are weighted and summed according to preset weights to obtain the comprehensive load score. The comprehensive load score is calculated as follows: the comprehensive load score equals the sum of the controller hardware resource occupancy status sub-item score multiplied by the first weight, the vehicle business task operation status sub-item score multiplied by the second weight, the communication link status sub-item score multiplied by the third weight, and the vehicle driving condition status sub-item score multiplied by the fourth weight. The weight value of each dimension is used to reflect the importance of that dimension in the comprehensive evaluation. The higher the weight, the greater the contribution of that dimension to the overall vehicle load and risk. The specific weight of each dimension can be configured according to the actual application scenario. Since the status information of different dimensions has different contributions to reflecting the overall operating pressure of the vehicle, for example, the vehicle business task operation status directly determines how many services are currently competing for computing and communication resources, and has the most direct impact on the condition judgment. Therefore, it can be assigned a relatively high weight, while dimensions with relatively small impact on the comprehensive load are assigned relatively low weights. By using a weighted summation method, state information from multiple heterogeneous dimensions is integrated into a comprehensive quantitative indicator.

[0094] After calculating the comprehensive load score, the vehicle's current operating condition level is determined based on this score. Different operating condition levels reflect different levels of vehicle workload and available resource status. For example, a higher score indicates a heavy load and scarce available resources, while a lower score indicates a light load and abundant available resources. The operating condition level can be determined by comparing the comprehensive load score with a preset threshold range. For example, a score higher than a first preset threshold indicates a high-load condition, a score lower than a second preset threshold indicates a low-load idle condition, and a score in between indicates a normal-load condition, where the first preset threshold is greater than the second preset threshold. By converting continuous comprehensive load scores into discrete operating condition levels, subsequent adjustments to transmission parameters and task priority configurations have a clear strategic basis, avoiding the problems of overly refined and unstable control strategies caused by directly using continuous scores.

[0095] The standardized score calculation methods for each dimension are as follows.

[0096] For the ECU hardware load dimension, this dimension includes three sub-features: CPU utilization, memory utilization, and Flash erase / write status. CPU utilization and memory utilization are expressed as percentages, while Flash erase / write status reflects the current write load level of the Flash memory. When calculating the standardized score for this dimension, CPU utilization, memory utilization, and Flash erase / write status are combined according to preset rules to obtain a standardized ECU hardware load score ranging from 0 to 100. The higher the score, the more strained the ECU's current hardware resources are, and the fewer available computing resources it has.

[0097] For the overall vehicle operation status dimension, this dimension includes four sub-features: frequency of power control task anomalies, number of vehicle-machine interaction glitches or timeouts, SOC monitoring deviation, and real-time charging operation status. The frequency of power control task anomalies reflects the frequency of anomalies in vehicle powertrain-related tasks; the number of vehicle-machine interaction glitches or timeouts reflects the smoothness of human-machine interaction; the SOC monitoring deviation reflects the accuracy of battery status monitoring; and the real-time charging operation status reflects the execution status of the current charging task. When calculating the standardized score for this dimension, the above four sub-features are positively normalized to obtain a standardized score for the overall vehicle operation status ranging from 0 to 100. A higher score indicates a heavier operational load at the current vehicle business level and a greater number of services requiring protection.

[0098] For the vehicular communication link status dimension, this dimension includes three sub-features: CAN or CANFD bus load rate, communication bit error rate, and single-frame transmission delay. The bus load rate reflects the current occupancy level of the communication bus, the communication bit error rate reflects the signal quality of the communication link, and the single-frame transmission delay reflects the real-time performance of data frame transmission on the bus. When calculating the standardized score for this dimension, the above three sub-features are positively normalized to obtain a standardized score for the vehicular communication link status ranging from 0 to 100. A higher score indicates a busier or lower-quality current communication link, and fewer available communication resources.

[0099] For the vehicle driving condition status dimension, this dimension includes three sub-features: driving speed, operating condition type coefficient, and vehicle and system power consumption. Driving speed reflects the vehicle's current driving state; higher speeds place higher demands on safety and real-time performance. The operating condition type coefficient distinguishes the vehicle's current operating scenario; this coefficient is lowest when parked, intermediate when driving, and highest when charging. Vehicle and system power consumption reflects the overall power consumption level of the vehicle; higher power consumption indicates more active operation of various vehicle systems and more intense competition for resources. When calculating the standardized score for this dimension, the three sub-features are positively normalized to obtain a standardized score for the vehicle driving condition status ranging from 0 to 100. A higher score indicates a more stringent constraint on resource availability for the upgrade task in the current vehicle operating scenario.

[0100] After obtaining standardized scores for the four dimensions, they are weighted and summed according to preset weights to obtain a comprehensive load score. The weights for the ECU hardware load dimension are 30%, the vehicle operation status dimension is 35%, the in-vehicle communication link status dimension is 20%, and the vehicle driving condition status dimension is 15%. A higher comprehensive load score indicates a heavier overall vehicle load and more limited available communication and computing resources for the upgrade task.

[0101] In this embodiment of the application, after obtaining the comprehensive load score, when the comprehensive load score belongs to the first preset score range (such as 71-100 points), it is determined that the current operating condition level of the vehicle is a high load condition, the corresponding data transmission amount is the first data volume threshold, and the corresponding transmission interval is the first time interval.

[0102] When the comprehensive load score falls within the second preset score range (e.g., 31-70 points), the current operating condition level of the vehicle is determined to be the normal load condition, the corresponding data transmission volume is the second data volume threshold, and the corresponding transmission interval is the second time interval.

[0103] When the comprehensive load score falls within the third preset score range (e.g., 0-30 points), the current operating condition level of the vehicle is determined to be a low load idle condition, the corresponding data transmission volume is the third data volume threshold, and the corresponding transmission interval is the third time interval.

[0104] Wherein, the first data volume threshold is less than the second data volume threshold, and the second data volume threshold is less than the third data volume threshold; the first time interval is greater than the second time interval, and the second time interval is greater than the third time interval.

[0105] In step S103, when adjusting the transmission data volume and transmission interval of the upgrade package data according to the operating condition level, the current operating condition level of the vehicle is first obtained. This operating condition level includes any one of high load condition, normal load condition, and low load idle condition, and different operating condition levels correspond to different transmission data volume and transmission interval configurations.

[0106] When the operating condition is high load, the amount of data transmitted is adjusted to the first data volume threshold (e.g., the single packet block length is reduced to 1024 bytes), and the transmission interval is adjusted to the first time interval (e.g., 20ms). Under high load conditions, the vehicle's bus resources are occupied by a large amount of service data, and available communication resources are scarce. Therefore, the minimum amount of data transmitted and the maximum transmission interval are adopted, so that each transmission occupies only a very small amount of bus bandwidth, and sufficient time gaps are left between two transmissions for service data to use, avoiding interference with the normal communication of the vehicle.

[0107] When the operating condition is at the normal load level, the transmitted data volume is adjusted to the second data volume threshold (e.g., the single packet block length is set to 4096 bytes), and the transmission interval is adjusted to the second time interval (e.g., 10ms). Under normal load conditions, the vehicle's bus resources are in a normal occupied state. There is a certain amount of business data that needs to be transmitted, and some idle bandwidth is also available for use. Therefore, a moderate transmitted data volume and a moderate transmission interval are adopted. While ensuring the priority transmission of business data, idle bandwidth is used appropriately for the transmission of upgrade data.

[0108] When the operating condition is low-load idle condition, the data transmission volume is adjusted to the third data volume threshold (e.g., the single packet block length is set to 8192 bytes), and the transmission interval is adjusted to the third time interval (e.g., 5ms). Under low-load idle condition, the vehicle's bus resources are relatively idle, and the bandwidth usage of service data is less. Therefore, the maximum data transmission volume and the shortest transmission interval are used to make full use of idle bandwidth resources to quickly complete the transmission of upgrade data and shorten the overall upgrade time.

[0109] Specifically, the first data volume threshold is less than the second data volume threshold, and the second data volume threshold is less than the third data volume threshold. This means that the data volume transmitted per transmission is minimal under high load conditions and maximum under low load and idle conditions. The first time interval is greater than the second time interval, and the second time interval is greater than the third time interval. This means that the waiting time between two transmissions is longest under high load conditions and shortest under low load and idle conditions. Through this differentiated configuration, the bus occupancy rate of the upgrade data stream automatically decreases as the vehicle load increases and automatically increases as the vehicle load decreases, achieving automatic avoidance between upgrade transmissions and vehicle services.

[0110] In this embodiment of the application, the upgrade package data adopts a splittable data structure, which is used to split the upgrade package data into multiple underlying data units, and each underlying data unit is transmitted and verified independently; the amount of data transmitted is the amount of data of the underlying data unit in a single transmission.

[0111] In some specific embodiments, the upgrade package data uses a splittable data structure. (Refer to...) Figure 2 This splittable data structure abandons the traditional single binary data stream format of upgrade packages, adopting a three-level structured splittable data structure, which from top to bottom includes the upgrade package master layer, the business data sub-packet layer, and the minimum transmission fragment layer. The upgrade package master layer, as the top-level management unit, contains the firmware version number, hardware matching version number, global verification field, and hierarchical splitting rule configuration words. The global verification field first generates a firmware global hash digest using the SHA-256 algorithm, and then superimposes a CRC32 checksum to form double verification. The business data sub-packet layer divides the complete firmware logic into multiple business sub-packets based on the ECUFlash storage partition and functional business modules. Each business sub-packet is independently encapsulated, carrying a unique sub-packet number, a sub-packet offset address, and a unique sub-packet checksum. The unique sub-packet number is encoded using a combination of domain ID, ECUID, and sub-packet sequence number. The sub-packet offset address accurately marks the corresponding Flash physical sector, starting offset address, and data length of the sub-packet. The minimum transmission fragmentation layer uses the UDS36 service as the transmission carrier and further splits each service sub-packet into multiple minimum transmission fragments. Each fragment has a built-in sub-packet number, dynamic fragment size, and fragment identity identifier.

[0112] Through the aforementioned three-level structured splitting method, the upgrade package data is no longer distributed as a single, indivisible whole. Each smallest transmission fragment is transmitted independently on the communication bus. The ECU receiver can quickly sort and detect missing fragments based on the sub-packet number and fragment sequence number built into each fragment. Each fragment undergoes independent validity verification. If any smallest transmission fragment is damaged or lost during transmission, only that fragment needs to be retransmitted, rather than the entire service sub-packet or the entire upgrade package. This reduces retransmission overhead in abnormal situations and improves the efficiency and robustness of upgrade transmission.

[0113] In this data structure, the amount of data transmitted is defined as the minimum data size of a single transmission fragment. Adjusting the amount of data transmitted under different operating conditions essentially means adjusting the size of the minimum data size of a single transmission fragment, i.e., the length of a UDS36 service single-packet block. Under high load conditions, the minimum data size of a single transmission fragment is reduced (e.g., 1024 bytes), resulting in shorter bus occupancy time for each transmission, less congestion of service data, and ensuring the communication needs of real-time vehicle services under high load conditions. Under low load and idle conditions, the minimum data size of a single transmission fragment is increased (e.g., 8192 bytes), allowing each transmission to carry more upgrade data, reducing the number of transmission interactions, and improving the transmission efficiency of upgrade data.

[0114] Because the upgrade package data adopts a three-level splittable data structure, the amount of data transmitted in a single upgrade data transmission is adjustable. It can be adapted to a fine granularity within the range of 1024 bytes to 8192 bytes according to different operating conditions, providing a data-level implementation foundation for time-sharing and peak-shifting transmission.

[0115] In step S104, during the specific data transmission process, the host computer splits the upgrade package data according to the adjusted transmission data volume. When the adjusted transmission data volume is small, a smaller amount of data is extracted from the upgrade package data each time and encapsulated into one or more bus messages for transmission; when the adjusted transmission data volume is large, a larger amount of data is extracted and transmitted each time. After each data transmission is completed, the host computer waits for the time length corresponding to the adjusted transmission interval before transmitting the next data volume.

[0116] In this way, the upgrade data stream no longer continuously occupies the communication bus in bursts of large traffic. Instead, it is divided into multiple data blocks according to the adjusted transmission data volume and distributed over time with adjusted transmission intervals. When the vehicle is under high load, the adjusted transmission data volume is reduced and the transmission interval is lengthened. The upgrade data stream is transmitted in sparse small data blocks interspersed in the time gaps of the vehicle's normal business data stream. The upgrade data and business data form a time-sharing and off-peak situation on the communication bus, each occupying different time periods and eliminating direct bandwidth competition between them. When the vehicle is under low load and idle, the adjusted transmission data volume is increased and the transmission interval is shortened. The upgrade data stream is distributed in compact large data blocks, making full use of the idle time slots left by the business data stream to quickly complete the transmission.

[0117] This time-sharing peak-shaving transmission mechanism rationally allocates communication bus resources in a time-dimensional manner, ensuring that upgrade data streams and normal vehicle service data streams are staggered in time. This eliminates the need for priority arbitration at the physical bus level, fundamentally eliminating resource competition between upgrade data and service data on the communication bus. During the upgrade process, the vehicle can still maintain normal driving control and vehicle-to-everything (V2X) interaction functions, without experiencing service interruptions or delays due to the bus being overwhelmed by upgrade data.

[0118] After the upgrade package data is distributed in a staggered manner, an upgrade task corresponding to the upgrade package data is created in step S105.

[0119] The upgrade task is a control logic unit used to manage and execute the entire upgrade process. It contains at least the following information: target controller identifier, which indicates the target controller to be upgraded corresponding to the upgrade task; upgrade package data index, which is used to associate the issued upgrade package data or the cached upgrade package data block; and upgrade task status, which records the current stage of the upgrade process, such as pending execution, in execution, paused, or completed.

[0120] By creating upgrade tasks, the previously discrete process of delivering upgrade package data and the subsequent upgrade execution process are linked into a complete upgrade flow. The creation of upgrade tasks provides a clear operational object for subsequent priority configuration and upgrade control, offering a logical framework for the full lifecycle management of the upgrade process. Simultaneously, the status information of the upgrade tasks provides a basis for recording and tracing the pause and resumption of the upgrade process during execution, offering the necessary data structure support for saving and restoring asynchronous scheduling interrupt contexts.

[0121] In step S106, after creating the upgrade task, the execution priority of the upgrade task is configured according to the operating condition level. When configuring the execution priority of the upgrade task, the current operating condition level of the vehicle is first obtained. This operating condition level includes any one of high-load, normal-load, and low-load idle conditions. Then, the position of the upgrade task relative to the vehicle's real-time and regular services is determined based on the operating condition level. Real-time vehicle services are those involving vehicle safety control, while regular services are non-core services that do not involve vehicle safety control.

[0122] Vehicle tasks are divided into multiple execution levels based on time periods, such as 10ms, 100ms, and 1s period tasks. Tasks of different period levels have different execution frequencies; tasks with shorter periods have higher execution frequencies and stricter requirements for response timeliness, and are usually assigned to real-time vehicle services with the highest real-time requirements.

[0123] When the operating condition is high-load, the upgrade task is configured with a priority lower than both real-time vehicle services and regular services; that is, the upgrade task has the lowest priority after all other service tasks. High-load conditions typically correspond to vehicle operation, where real-time vehicle services are running intensively, and communication bus and computing resources are under heavy load. Under this priority configuration, the upgrade task is assigned to the longest-running periodic task queue for execution, acquiring computing resources only between the execution intervals of real-time and regular vehicle services. Simultaneously, the amount of data written to Flash in a single operation is limited to no more than 1KB, minimizing the impact of each write operation on bus and computing resources and avoiding any perceptible impact on the response time of safety-critical services such as power control and fault diagnosis.

[0124] When the operating condition is at the normal load level, the upgrade task is configured with a priority lower than the vehicle's real-time services but higher than or equal to the normal services. In other words, the upgrade task's priority is between or equal to that of the vehicle's real-time services and normal services. Normal load conditions typically correspond to the vehicle being stationary during charging or operating under light load. At this time, the vehicle's real-time services operate at low frequency, while normal services remain active but have relatively relaxed response time requirements. Under this priority configuration, the upgrade task and normal services are assigned to the same periodic task queue for execution. They share computing resources but avoid mutual blocking through an asynchronous scheduling mechanism. Flash write operations are executed periodically according to a preset write interval (e.g., 50ms). After completing one data block write within each write cycle, the upgrade task actively yields resources, waiting for the next write cycle to arrive before continuing execution.

[0125] When the operating condition is low-load idle, upgrade tasks are configured with a priority lower than real-time vehicle services but higher than regular services. This means upgrade tasks receive computing resources only after real-time vehicle services and before regular services. Low-load idle typically corresponds to a vehicle being parked and no core services running, at which point most system resources are idle. Under this priority configuration, upgrade tasks are assigned to the shortest-duration period task queue for execution, receiving computing resources at the highest execution frequency. Regular services are assigned to a periodic task queue with an intermediate time period, between the shortest and longest time periods.

[0126] Reference Figure 4 For example, when a vehicle is assessed as stationary or parked, i.e., in a low-load idle state, the core vehicle services operate at low frequency, and system resources are abundant. In this case, upgrade task A (e.g., task A1) is adjusted to a high-priority task and assigned to a 10ms periodic task queue for execution. This allows the upgrade task to obtain computing resources at the highest execution frequency, accelerating the upgrade process. Simultaneously, core services B (e.g., tasks B1 and B2), which originally ran in 10ms periodic tasks, are adjusted to low-priority tasks and scheduled for execution in 100ms and 1s periodic tasks. Since the triggering frequency of core services is inherently low in the parked state, assigning them to longer periodic tasks will not affect driving safety. In this scenario, upgrade task A1 executes continuously in the 10ms periodic task queue, while core services B1 and B2 execute according to their respective cycles in the 100ms and 1s periodic tasks, with the two types of tasks running in parallel in task queues with different time periods.

[0127] During the upgrade task execution, a global event interrupt is triggered after each data packet is downloaded to Flash. This global event interrupt is used to reacquire multi-dimensional real-time operating status information of the vehicle and reassess the vehicle's current operating condition level to determine whether the task priority needs to be adjusted. If the operating condition level is still low-load idle after reassessment, the current priority configuration is maintained, the upgrade task continues to execute in the 10ms cycle task, and the core business continues to execute in the 100ms and 1s cycle tasks.

[0128] If a change in the operational condition level is detected after reassessment, such as a vehicle switching from parked to driving, a priority reassignment process is triggered. At this time, the current upgrade task A1 is paused via an asynchronous event, and its execution priority is reconfigured based on the changed operational condition level. When the operational condition level changes to a high-load condition, the priority of upgrade task A1 is reduced, and it is assigned to a 100ms or 1s cycle task for execution, reducing the frequency of computational resource consumption by the upgrade task. Simultaneously, core services B1 and B2, originally assigned to 100ms and 1s cycle tasks, are reassigned to 10ms cycle tasks via asynchronous scheduling, ensuring that critical driving safety services regain the highest response time. Upgrade task A1 and core services B1 and B2 achieve dynamic switching and scheduling between task queues with different time cycles, achieving seamless transition in business execution. This ensures that critical driving safety services always have the highest response priority while fully utilizing the ample resources available during parked or idle states to rapidly advance the upgrade progress.

[0129] Through the above-mentioned differentiated priority configuration based on the operating condition level, the execution priority of the upgrade task automatically decreases as the vehicle load increases and automatically increases as the vehicle load decreases, thus realizing automatic avoidance of upgrade tasks and vehicle services at the computing resource level.

[0130] In step S107, when the target controller is being upgraded, the upgrade package data is first written to its inactive storage partition according to the execution priority of the upgrade task. The inactive storage partition is a backup storage area in the target controller that is physically isolated from the currently running partition. Writing to this partition will not affect the applications and business functions currently running on the target controller.

[0131] During the write process of the upgrade package data, high-priority vehicle real-time service trigger events are continuously monitored. This monitoring process checks for any high-priority vehicle real-time services that need to be executed after each step or data block of the write operation is completed. When no trigger event is detected, the write operation continues. When a vehicle real-time service trigger event is detected, the target controller pauses the current write operation and records the position information of the written data as an interrupt context. The interrupt context includes at least the identifier of the currently being written service sub-packet, the length of the written data, and the offset of the next data to be written, providing accurate breakpoint information when resuming the write operation.

[0132] After the write operation is paused, the target controller switches to real-time vehicle service execution. At this time, the target controller's computing resources are released from the upgrade task and reallocated to real-time vehicle services, ensuring that the execution of safety-critical services is not blocked by the upgrade task.

[0133] Once the vehicle's real-time services are completed, an asynchronous event is generated to notify the upgrade task to resume execution. This asynchronous event is a signal triggered by the completion of the vehicle's real-time services. The upgrade task does not need to actively query whether the real-time services have been completed; it only needs to perform the corresponding recovery operation upon receiving this asynchronous event. This avoids the upgrade task continuously occupying processor resources for invalid queries during the waiting period, as is common in polling methods.

[0134] Based on this asynchronous event, the target controller resumes writing the upgrade package data from the data position where writing was paused, according to the interrupt context. The write operation starts from the offset of the next data position to be written recorded in the interrupt context and continues writing the remaining upgrade package data, neither rewriting the completed parts nor skipping the parts that have not yet been written.

[0135] The process of pausing write operations, switching to real-time business execution, asynchronous event recovery, and resuming write operations from the breakpoint may be repeated multiple times during the write process of the upgrade package data until all upgrade package data is completely written to the inactive storage partition, thus completing the flashing of the inactive storage partition. Throughout the flashing process, the write operation of the upgrade task is divided into multiple pauseable and resumable segments. High-priority vehicle real-time services can interrupt the upgrade write process at any time and obtain computing resources. The upgrade write process will not have any perceptible impact on the response timeliness of safety-critical services. Simultaneously, the recording of interrupt context and the recovery based on the interrupt context enable the upgrade write process to resume from the last paused position each time it resumes, without restarting the entire write process or losing already written data. This ensures that the upgrade task can still be completed efficiently even after multiple interruptions by real-time services.

[0136] For the target controller, a dynamic circular queue cache module is built on the target controller side to connect with the upgrade package data issued by the host computer, and realize data caching, sorting and anomaly cleaning.

[0137] After receiving the minimum transmission fragments of the upgrade package data from the host computer, the ECU first performs a validity check on each fragment. The check includes verifying the fragment checksum to confirm that the fragment has not been damaged during transmission. Fragments that fail the check are discarded, and a retransmission request is sent to the management terminal. Valid data is automatically sorted by fragment sequence number and sub-packet number and then enqueued. The circular queue has a preset maximum buffer capacity, which can be set to 64KB based on the ECU's memory resources to avoid excessive memory consumption.

[0138] During data caching, the retention time of data units stored in the queue is monitored in real time. For data units whose retention time exceeds a preset timeout threshold, such as fragments that have not formed a complete business sub-package after more than 30 seconds, they are automatically determined to be invalid data, removed from the queue, and the corresponding cache space is released. For detected duplicate fragments and out-of-order data, they are directly intercepted and removed, and are not allowed to be enqueued to avoid cache overflow, memory leaks, and data interference.

[0139] Once all the smallest transmission fragments belonging to the same service sub-packet in the queue have been collected, the sub-packet reassembly process is automatically triggered, concatenating these fragments into a complete service sub-packet according to their fragment sequence numbers. After reassembly, the service sub-packet is transferred to the upgrade preprocessing queue, awaiting asynchronous scheduling to perform the Flash write operation.

[0140] Reference Figure 5 This application also provides an upgrade device for an on-board controller, comprising:

[0141] The acquisition module 201 is used to acquire multi-dimensional real-time operating status information of the vehicle.

[0142] The operating condition level determination module 202 is used to determine the current operating condition level of the vehicle based on the multi-dimensional real-time operating status information.

[0143] The adjustment module 203 is used to adjust the amount of data transmitted and the transmission interval of the upgrade package data according to the operating condition level.

[0144] The distribution module 204 is used to distribute the upgrade package data to the target controller through the communication bus according to the adjusted transmission data volume and transmission interval, so that the upgrade data stream and the normal vehicle business data stream are transmitted in a time-sharing and staggered manner on the communication bus.

[0145] Module 205 is used to create an upgrade task corresponding to the upgrade package data;

[0146] The priority configuration module 206 is used to configure the execution priority of the upgrade task according to the operating condition level;

[0147] The control module 207 is used to control the target controller to perform an upgrade based on the upgrade package data according to the execution priority of the upgrade task.

[0148] Preferably, the adjustment module includes:

[0149] The first adjustment unit is used to adjust the amount of transmitted data to a first data amount threshold and the transmission interval to a first time interval when the operating condition level is a high load condition.

[0150] The second adjustment unit is used to adjust the amount of transmitted data to a second data amount threshold and the transmission interval to a second time interval when the operating condition level is a normal load condition.

[0151] The third adjustment unit is used to adjust the amount of transmitted data to a third data amount threshold and the transmission interval to a third time interval when the operating condition level is a low load idle condition.

[0152] The first data volume threshold is less than the second data volume threshold, and the second data volume threshold is less than the third data volume threshold; the first time interval is greater than the second time interval, and the second time interval is greater than the third time interval.

[0153] Preferably, the priority configuration module includes:

[0154] The first priority configuration unit is used to configure the upgrade task to a priority lower than the vehicle real-time service and lower than the regular service when the operating condition level is high load condition, and the upgrade task is assigned to the periodic task queue with the longest time period for execution.

[0155] The second priority configuration unit is used to configure the upgrade task to a priority lower than the vehicle real-time service but higher than or equal to the regular service when the operating condition level is a normal load condition. The upgrade task and the regular service are assigned to the periodic task queue with the same time period for execution.

[0156] The third priority configuration unit is used to configure the upgrade task as having a priority lower than the vehicle real-time service but higher than the regular service when the operating condition level is low load idle condition. The upgrade task is assigned to the shortest time period period task queue for execution, and the regular service is assigned to the intermediate time period period task queue for execution. The intermediate time period is between the shortest time period and the longest time period.

[0157] The real-time vehicle services refer to services involving vehicle safety control, while the routine services refer to non-core services that do not involve vehicle safety control.

[0158] Preferably, the control module includes:

[0159] The first control unit is configured to control the target controller to write the upgrade package data into its inactive storage partition according to the execution priority of the upgrade task.

[0160] The monitoring unit is used to monitor high-priority triggering events of the vehicle's real-time services during the writing process of the upgrade package data.

[0161] The interrupt unit is used to control the target controller to pause the current write operation and record the location information of the written data as the interrupt context when a trigger event of the vehicle's real-time service is detected.

[0162] The second control unit is used to control the target controller to switch to the real-time business execution of the vehicle after the writing is paused;

[0163] An asynchronous event generation unit is used to generate an asynchronous event to notify the upgrade task to resume execution after the real-time service of the vehicle has been completed.

[0164] The third control unit is used to control the target controller to continue writing the upgrade package data from the data position at the time of the paused writing, according to the interrupt context, based on the asynchronous event, until the burning of the inactive storage partition is completed.

[0165] This application also provides a vehicle including the aforementioned upgrade device for the vehicle controller.

[0166] It should be understood that the application of this application is not limited to the examples above. Those skilled in the art can make improvements or modifications based on the above description, and all such improvements and modifications should fall within the protection scope of the appended claims. Those skilled in the art can understand that implementing all or part of the processes of the above embodiments and making equivalent changes according to the claims of this application still fall within the scope of this application.

Claims

1. A method for upgrading an on-board controller, characterized in that, include: Obtain multi-dimensional real-time operating status information of vehicles; Based on the multi-dimensional real-time operating status information, the current operating condition level of the vehicle is determined; Adjust the amount of data transmitted and the transmission interval of the upgrade package data according to the aforementioned operating condition level; According to the adjusted data transmission volume and transmission interval, the upgrade package data is sent to the target controller through the communication bus, so that the upgrade data stream and the normal vehicle business data stream are transmitted on the communication bus in a time-sharing and staggered manner. Create an upgrade task corresponding to the upgrade package data; Configure the execution priority of the upgrade task according to the aforementioned operating condition level; Based on the execution priority of the upgrade task, the target controller is controlled to perform an upgrade based on the upgrade package data.

2. The method according to claim 1, characterized in that, The multi-dimensional real-time operating status information includes: controller hardware resource occupancy status, vehicle business task operating status, communication link status, and vehicle driving condition status. The steps for determining the current operating condition level of the vehicle based on this multi-dimensional real-time operating status information include: The controller hardware resource occupancy status, the vehicle business task operation status, the communication link status, and the vehicle driving condition status are respectively quantified to generate sub-item scores for each dimension; The scores of each sub-item are weighted and summed according to preset weights to obtain the comprehensive load score. Based on the comprehensive load score, the current operating condition level of the vehicle is determined.

3. The method according to claim 2, characterized in that, The steps for determining the current operating condition level of the vehicle based on the comprehensive load score include: When the comprehensive load score belongs to the first preset score range, the current operating condition level of the vehicle is determined to be a high load condition, the corresponding data transmission volume is the first data volume threshold, and the corresponding transmission interval is the first time interval. When the comprehensive load score belongs to the second preset score range, the current operating condition level of the vehicle is determined to be the normal load condition, the corresponding data transmission volume is the second data volume threshold, and the corresponding transmission interval is the second time interval. When the comprehensive load score belongs to the third preset score range, the current operating condition level of the vehicle is determined to be low load idle condition, the corresponding data transmission amount is the third data volume threshold, and the corresponding transmission interval is the third time interval. Wherein, the first data volume threshold is less than the second data volume threshold, and the second data volume threshold is less than the third data volume threshold; the first time interval is greater than the second time interval, and the second time interval is greater than the third time interval.

4. The method according to claim 1 or 3, characterized in that, The steps for adjusting the transmission volume and transmission interval of the upgrade package data according to the aforementioned operating condition level include: When the operating condition level is high load condition, the amount of data transmitted is adjusted to a first data amount threshold, and the transmission interval is adjusted to a first time interval; When the operating condition level is normal load condition, the amount of data transmitted is adjusted to the second data amount threshold, and the transmission interval is adjusted to the second time interval; When the operating condition level is low load idle condition, the amount of data transmitted is adjusted to the third data amount threshold, and the transmission interval is adjusted to the third time interval; The first data volume threshold is less than the second data volume threshold, and the second data volume threshold is less than the third data volume threshold; the first time interval is greater than the second time interval, and the second time interval is greater than the third time interval.

5. The method according to claim 4, characterized in that, The upgrade package data adopts a splittable data structure, which is used to split the upgrade package data into multiple underlying data units, and each underlying data unit is transmitted and verified independently; the amount of data transmitted is the amount of data of the underlying data unit in a single transmission.

6. The method according to claim 1 or 3, characterized in that, The steps for configuring the execution priority of the upgrade task according to the aforementioned operating condition level include: When the operating condition level is high load condition, the upgrade task is configured with a priority lower than the vehicle real-time service and lower than the regular service, and the upgrade task is assigned to the periodic task queue with the longest time period for execution. When the operating condition level is normal load condition, the upgrade task is configured with a priority lower than the vehicle real-time service but higher than or equal to the normal service, and the upgrade task and the normal service are assigned to the periodic task queue with the same time period for execution. When the operating condition level is low load idle condition, the upgrade task is configured with a priority lower than the vehicle real-time service but higher than the regular service. The upgrade task is assigned to the shortest time period period task queue for execution, and the regular service is assigned to the intermediate time period period task queue for execution. The intermediate time period is between the shortest time period and the longest time period. The real-time vehicle services refer to services involving vehicle safety control, while the routine services refer to non-core services that do not involve vehicle safety control.

7. The method according to claim 3, characterized in that, The steps for controlling the target controller to perform an upgrade based on the upgrade package data, according to the execution priority of the upgrade task, include: According to the execution priority of the upgrade task, the target controller is controlled to write the upgrade package data to its inactive storage partition; During the writing of the upgrade package data, the system listens for high-priority trigger events of the vehicle's real-time services. When a trigger event for the vehicle's real-time service is detected, the target controller is controlled to pause the current write operation and record the location information of the written data as an interrupt context. After pausing the write operation, control the target controller to switch to the vehicle's real-time service execution. Once the real-time vehicle service is completed, an asynchronous event is generated to notify the upgrade task to resume execution. Based on the asynchronous event, the target controller is controlled to continue writing the upgrade package data from the data position where writing was paused, according to the interrupt context, until the burning of the inactive storage partition is completed.

8. An upgrade device for an on-board controller, characterized in that, include: The acquisition module is used to acquire multi-dimensional real-time operating status information of the vehicle. The operating condition level determination module is used to determine the current operating condition level of the vehicle based on the multi-dimensional real-time operating status information. The adjustment module is used to adjust the amount of data transmitted and the transmission interval of the upgrade package data according to the operating condition level. The distribution module is used to distribute the upgrade package data to the target controller through the communication bus according to the adjusted transmission data volume and transmission interval, so that the upgrade data stream and the normal vehicle business data stream are transmitted in a time-sharing and staggered manner on the communication bus. A creation module is used to create an upgrade task corresponding to the upgrade package data; The priority configuration module is used to configure the execution priority of the upgrade task according to the operating condition level; The control module is used to control the target controller to perform an upgrade based on the upgrade package data according to the execution priority of the upgrade task.

9. The apparatus according to claim 8, characterized in that, The adjustment module includes: The first adjustment unit is used to adjust the amount of transmitted data to a first data amount threshold and the transmission interval to a first time interval when the operating condition level is a high load condition. The second adjustment unit is used to adjust the amount of transmitted data to a second data amount threshold and the transmission interval to a second time interval when the operating condition level is a normal load condition. The third adjustment unit is used to adjust the amount of transmitted data to a third data amount threshold and the transmission interval to a third time interval when the operating condition level is a low load idle condition. The first data volume threshold is less than the second data volume threshold, and the second data volume threshold is less than the third data volume threshold; the first time interval is greater than the second time interval, and the second time interval is greater than the third time interval.

10. The apparatus according to claim 8, characterized in that, The priority configuration module includes: The first priority configuration unit is used to configure the upgrade task to a priority lower than the vehicle real-time service and lower than the regular service when the operating condition level is high load condition, and the upgrade task is assigned to the periodic task queue with the longest time period for execution. The second priority configuration unit is used to configure the upgrade task to a priority lower than the vehicle real-time service but higher than or equal to the regular service when the operating condition level is a normal load condition. The upgrade task and the regular service are assigned to the periodic task queue with the same time period for execution. The third priority configuration unit is used to configure the upgrade task as having a priority lower than the vehicle real-time service but higher than the regular service when the operating condition level is low load idle condition. The upgrade task is assigned to the shortest time period period task queue for execution, and the regular service is assigned to the intermediate time period period task queue for execution. The intermediate time period is between the shortest time period and the longest time period. The real-time vehicle services refer to services involving vehicle safety control, while the routine services refer to non-core services that do not involve vehicle safety control.

11. The apparatus according to claim 8, characterized in that, The control module includes: The first control unit is configured to control the target controller to write the upgrade package data into its inactive storage partition according to the execution priority of the upgrade task. The monitoring unit is used to monitor high-priority triggering events of the vehicle's real-time services during the writing process of the upgrade package data. The interrupt unit is used to control the target controller to pause the current write operation and record the location information of the written data as the interrupt context when a trigger event of the vehicle's real-time service is detected. The second control unit is used to control the target controller to switch to the real-time business execution of the vehicle after the writing is paused; An asynchronous event generation unit is used to generate an asynchronous event to notify the upgrade task to resume execution after the real-time service of the vehicle has been completed. The third control unit is used to control the target controller to continue writing the upgrade package data from the data position at the time of the paused writing, according to the interrupt context, based on the asynchronous event, until the burning of the inactive storage partition is completed.

12. A vehicle, characterized in that, The upgrade device includes the vehicle controller as described in any one of claims 8-11.

Images