Software upgrading method and device, equipment and storage medium

Abstract

The embodiment of the invention provides a software upgrading method and device, equipment and a storage medium, and the method comprises the steps: obtaining a first vehicle list, and recording a plurality of vehicles located in the same region in the first vehicle list; obtaining vehicle end wireless capability data and / or network end wireless capability data of each vehicle; calculating a priority index of the vehicle according to the vehicle end wireless capability data of the vehicle and / or the network end wireless capability data of the vehicle; sorting according to the priority indexes of the vehicles, and starting from the vehicle with the highest priority index, selecting a first target number of vehicles from the first vehicle list as target vehicles; and performing software upgrading on the target vehicle. According to the embodiment of the invention, the software upgrading efficiency of the vehicle in a vehicle dense scene can be improved.

Description

Technical Field

[0001] This application relates to the field of software upgrade technology, and in particular to a software upgrade method, apparatus, device and storage medium. Background Technology

[0002] As vehicles become increasingly intelligent and car owners demand more features and functions, automakers continuously iterate and upgrade vehicle software, often via Over-The-Air (OTA) updates. With the accelerated iteration of intelligent connected vehicle functions, OTA update packages are becoming larger and more frequent, placing significant pressure on mobile networks. The current mainstream solution involves automakers distributing update packages via internet CDNs, which are then distributed indiscriminately to all vehicles through carrier networks.

[0003] However, in special areas with high vehicle density, such as finished product parking lots of vehicle manufacturing plants, container stacking areas of large ports, and vehicle transfer areas of logistics hubs, the physical distribution of vehicles is highly concentrated (up to hundreds or even thousands of vehicles), and network access requests have extremely strong spatiotemporal consistency. Traditional "one-size-fits-all" OTA push solutions suffer from problems such as insufficient wireless resources and air interface congestion, which affect the efficiency of vehicle software upgrades. Summary of the Invention

[0004] This application provides a software upgrade method, apparatus, device, and storage medium that can improve the efficiency of vehicle software upgrades in densely populated vehicle scenarios.

[0005] In a first aspect, embodiments of this application provide a software upgrade method, comprising: obtaining a first vehicle list, wherein the first vehicle list records multiple vehicles located in the same area; obtaining vehicle-side wireless capability data and / or network-side wireless capability data for each vehicle; calculating a priority index for the vehicles based on the vehicle-side wireless capability data and / or the vehicle-side wireless capability data; sorting the vehicles according to their priority index, and selecting a first target number of vehicles from the first vehicle list, starting with the vehicle with the highest priority index, as target vehicles; and performing a software upgrade on the target vehicles. In this method, the priority index of the vehicles can be calculated based on their vehicle-side wireless capability data and network-side wireless capability data, and a first target number of vehicles with relatively high priority indices can be selected for software upgrades. This solves the problem of systemic congestion of wireless resources caused by a lack of fine-grained scheduling in areas with high vehicle density, achieves rational allocation of resources for group efficiency, and improves the efficiency of vehicle software upgrades.

[0006] In one possible implementation, the vehicle-side wireless capability data includes at least one of the following parameters: call detail record usage, APN activation frequency, online duration, signal strength, and signal-to-noise ratio; and / or, the network-side wireless capability data includes at least one of the following parameters: base station-side real-time load rate, cell-level channel quality, and user plane latency.

[0007] In one possible implementation, calculating the vehicle's priority index based on the vehicle's on-board wireless capability data and / or the vehicle's network-side wireless capability data includes: normalizing the parameters included in the vehicle's on-board wireless capability data to obtain normalized on-board wireless capability data; and / or normalizing the parameters included in the vehicle's network-side wireless capability data to obtain normalized network-side wireless capability data; and calculating the vehicle's priority index based on the vehicle's normalized on-board wireless capability data and / or the vehicle's normalized network-side wireless capability data.

[0008] In one possible implementation, the method further includes: obtaining the historical average upgrade rate for each vehicle; and calculating a vehicle priority index based on the vehicle's vehicle-side normalized radio capability data and / or the vehicle's network-side normalized radio capability data, including: calculating the vehicle priority index based on the vehicle's vehicle-side normalized radio capability data and / or the vehicle's network-side normalized radio capability data, and based on the vehicle's historical average upgrade rate.

[0009] In one possible implementation, the priority index of the first vehicle is calculated based on the vehicle-side normalized radio capability data and the network-side normalized radio capability data of the first vehicle, and based on the vehicle's historical average upgrade rate. This includes calculating the vehicle's priority index according to the following formula: PF-OTA-E_i=[(α·D_norm_i+β·F_norm_i+γ·T_norm_i)·(δ·R_norm_i+ζ·S_norm_i+η·C_norm_i)] / [ (L_norm_i +ε)·(R_hist_i+μ)·(P_norm_i +ν) ]; where PF-OTA-E_i represents the priority index of vehicle i; D_norm_i represents the normalized call detail record usage of vehicle i; F_norm_i represents the normalized APN activation frequency of vehicle i; T_norm_i represents the normalized online duration of vehicle i; R_norm_i represents the normalized signal strength of vehicle i; S_norm_i represents the normalized signal-to-noise ratio of vehicle i; C_norm_i represents the normalized cell-level channel quality of vehicle i; L_norm_i represents the normalized real-time load rate of the base station side of vehicle i; R_hist_i represents the historical average upgrade rate of vehicle i; P_norm_i represents the normalized user plane latency of vehicle i; α, β, γ, δ, ζ, and η are weighting coefficients, and ε, μ, and ν are constants.

[0010] In one possible implementation, the software upgrade of the target vehicle includes: determining the upgrade time of the target vehicle; sending the target vehicle information and the upgrade time to the TSP platform and the network capability open platform respectively, so that the TSP platform notifies the target vehicle to start the software upgrade at the upgrade time, and the network capability open platform allocates support resources to the target vehicle at the upgrade time.

[0011] One possible implementation also includes: receiving upgrade-related data of the target vehicle; and adjusting the weighting coefficients based on the upgrade-related data of the target vehicle.

[0012] Secondly, embodiments of this application provide a software upgrade device, comprising: The module is used to obtain a first vehicle list, which records multiple vehicles located in the same area; and to obtain the vehicle-side wireless capability data and / or network-side wireless capability data of each vehicle. The calculation module is used to calculate the vehicle's priority index based on the vehicle's on-board wireless capability data and / or the vehicle's network-side wireless capability data. The selection module is used to sort vehicles according to their priority index, and select the first target number of vehicles from the first vehicle list, starting with the vehicle with the highest priority index, as the target vehicles; The upgrade module is used to upgrade the software of the target vehicle.

[0013] Thirdly, embodiments of this application provide an electronic device, including: a processor and a memory; wherein one or more computer programs are stored in the memory, the one or more computer programs including instructions that, when executed by the processor, cause the electronic device to perform the method described in any of the first aspects.

[0014] Fourthly, embodiments of this application provide a chip module, including the software upgrade device of the second aspect, or the method of performing any of the first aspects.

[0015] Fifthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when run on a computer, causes the computer to perform the method of any one of the first aspects.

[0016] In a sixth aspect, embodiments of this application provide a computer program product, which includes a computer program that, when run on a computer, causes the computer to perform the method of any one of the first aspects. Attached Figure Description

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

[0018] Figure 1 A schematic diagram of a system architecture provided for an embodiment of this application; Figure 2 A schematic diagram of a system structure applicable to the software upgrade method provided in the embodiments of this application; Figure 3 A flowchart illustrating a software upgrade method provided in an embodiment of this application; Figure 4 A schematic diagram illustrating the implementation flow of one step in the software upgrade method provided in this application embodiment; Figure 5 Another flowchart illustrating the software upgrade method provided in this application embodiment; Figure 6 Another flowchart illustrating the software upgrade method provided in this application embodiment; Figure 7 This is a schematic diagram of a software upgrade device provided in an embodiment of this application. Detailed Implementation

[0019] The terminology used in the implementation section of this application is for the purpose of explaining specific embodiments of this application only, and is not intended to limit this application.

[0020] First, the terms used in the embodiments of this application will be described by way of example rather than limitation.

[0021] OTA (Over-The-Air) is a technology that remotely distributes data, updates systems, or fixes vulnerabilities via wireless networks (such as Wi-Fi or mobile data). Users can easily upgrade and maintain their devices without needing to connect a data cable.

[0022] Call detail record (CDR) usage: Mobile data traffic consumed by a terminal within a unit period, which can be measured in megabytes (MBytes).

[0023] Access Point Name (APN) Activation Frequency: The number of times a terminal establishes an APN connection within a unit period.

[0024] Online duration: The total duration for which the terminal is in a communicable state within a unit period, which can be measured in minutes.

[0025] Signal strength: Signal strength refers to the strength of the signal received or transmitted by mobile terminals and other devices. Commonly used units are decibels (dB) and milliwatt decibels (dBm). Reference signal received power (RSRP) is one of the indicators for measuring signal strength.

[0026] Signal-to-noise ratio (SNR): also known as signal to interference plus noise ratio (SNR), the unit can be decibels (dB).

[0027] Real-time load rate on the base station side: This typically refers to the ratio of the actual amount of data transmitted by a communication base station within a specific time period to its theoretical maximum transmission capacity. It is used to evaluate the efficiency of network resource utilization and system performance. In this embodiment, the CPU utilization rate or bandwidth utilization rate of the base station can be used as the real-time load rate on the base station side, or the real-time load rate on the base station side can be calculated based on information such as the CPU utilization rate and bandwidth utilization rate of the base station.

[0028] Cell-level channel quality: The measurement results of the channel quality of the terminal by the base station, such as the Channel Quality Indicator, is one of the indicators that characterize the cell-level channel quality of the terminal.

[0029] User plane latency: The network latency of data from the base station to the core network during data transmission by the terminal, which can be measured in milliseconds (ms).

[0030] As cars become increasingly intelligent and car owners demand more and more features and functions from their vehicles, major automakers are constantly iterating and upgrading the vehicle's software. Automakers frequently use OTA (Over-The-Air) technology to upgrade vehicle software, and the frequency of upgrades is increasing, the size of software upgrade packages is growing, and the pressure on wireless networks is also increasing.

[0031] like Figure 1 As shown, the existing solutions for OTA-based software upgrades for vehicles mainly include: the OTA backend of the car manufacturer deploys the software upgrade package to the CDN server via the Internet; the CDN server actively pushes the upgrade to vehicles in the market or factory; and the software upgrade package is distributed to the vehicle's in-vehicle equipment, such as the in-vehicle communication module (Telematics Box, TBOX), through the operator's IP network and wireless transmission network. After receiving the software upgrade package, the in-vehicle equipment performs software updates to improve vehicle performance and functions.

[0032] However, in special areas with high vehicle density, such as finished product parking lots at vehicle manufacturing plants, container stacking areas at large ports, and vehicle transfer areas at logistics hubs, the physical distribution of vehicles is highly concentrated, sometimes reaching hundreds or even thousands of vehicles. Moreover, network access requests exhibit extremely strong spatiotemporal consistency. The aforementioned "one-size-fits-all" software upgrade solution has inherent and insurmountable flaws: First, wireless resource contention and congestion: A large number of vehicles simultaneously initiate download requests, far exceeding the carrying capacity of a single base station cell, leading to air interface congestion and a sharp decline in overall upgrade efficiency.

[0033] Second, unreasonable resource allocation: The existing software upgrade scheme implements the software upgrade scheme in the same way for all vehicles. "High-traffic vehicles" (such as vehicles that are conducting autonomous driving road tests or continuously reporting logs) will compete equally with "silent vehicles" for scarce wireless resources, resulting in unreasonable resource allocation.

[0034] Third, lack of network status awareness: The vehicle manufacturer's platform cannot obtain the wireless channel quality (such as RSRP, SINR) and base station load status of each vehicle in real time and accurately, and the scheduling decision is like "the blind men and the elephant".

[0035] Fourth, business interference: Other network services running concurrently in the vehicle (such as entertainment system updates and data reporting) will compete for software download bandwidth, resulting in a slow and easily interrupted upgrade process.

[0036] Therefore, embodiments of this application provide a software upgrade method, apparatus, device, and storage medium that can improve the efficiency of vehicle software upgrades in densely populated vehicle scenarios and enhance user experience.

[0037] In addition, reasonable allocation of wireless resources can be made for vehicle software upgrades to reduce the impact of other concurrent network services on software upgrades.

[0038] Figure 2 This is a schematic diagram of a system architecture to which the software upgrade method of this application is applicable, such as... Figure 2 As shown, it includes: several vehicles, a wireless transmission network provided by the operator, a CDN server, a network capability open platform, a Telematics Service Provider (TSP) platform, and an OTA management platform.

[0039] CDN servers are used to distribute software upgrade packages to each vehicle.

[0040] The network capability open platform is used to support the querying of network-side wireless capability data of vehicles, as well as to control the base station to reserve and allocate resources to vehicles.

[0041] The TSP platform is used for vehicle management, managing basic vehicle data and related data reported by the vehicle, such as vehicle-side wireless capability data. The TSP platform can be provided by the vehicle manufacturer, for example.

[0042] The OTA management platform is used to manage vehicle software upgrades. The OTA management platform can be provided by the automaker or a service provider; this application embodiment does not impose any restrictions, as long as the OTA management platform and the TSP platform can support the data communication required in this application embodiment.

[0043] The following is a combination of the above. Figure 1 and Figure 2 The system shown illustrates the software upgrade method provided in the embodiments of this application.

[0044] Figure 3 This is a flowchart illustrating a software upgrade method provided in an embodiment of this application. Figure 3 The illustrated embodiment can be executed by an OTA management platform. For example... Figure 3 As shown, the method may include: Step 301: Obtain the first vehicle list, which records multiple vehicles located in the same area.

[0045] For ease of explanation, in this embodiment, the area where the vehicles in the first vehicle list are located is referred to as the target area. The target area can be any area where vehicles requiring software upgrades are densely concentrated. This embodiment does not limit the size of the target area or the density of vehicles within it. For example, the target area can be a finished product parking lot at a vehicle manufacturing plant, a container stacking area at a large port, or a vehicle transfer area at a logistics hub.

[0046] In some embodiments, the TSP platform may record a list of vehicles corresponding to each densely populated vehicle area. The TSP platform sends the first list of vehicles corresponding to the target area to the OTA management platform, triggering the OTA management platform to initiate software upgrades for the vehicles in the first list of vehicles. Accordingly, the OTA management platform obtains the first list of vehicles.

[0047] For example, the TSP platform can record a corresponding vehicle list for each finished vehicle parking lot, which is used to record the vehicles parked in that finished vehicle parking lot. Then any of the finished vehicle parking lots mentioned above can be the target area, and the vehicle list corresponding to the finished vehicle parking lot is the first vehicle list mentioned above.

[0048] In some embodiments, relevant personnel from a car manufacturer can log in to the OTA management platform, upload a list of first vehicles corresponding to the target region, and trigger the OTA management platform to initiate a software upgrade for the first vehicles in the target region.

[0049] In some embodiments, the TSP platform can send a total vehicle list to the OTA management platform. This total vehicle list records all vehicles for which the automaker needs software upgrades. The OTA management platform obtains base station information for each vehicle in the target vehicle list from the network capability open platform. Based on this information, it determines that some vehicles are connected to the same base station or several adjacent base stations. If the number of such vehicles reaches a threshold, then the vehicles connected to the same base station are located in the same target area. The vehicle list consisting of these vehicles is designated as the first vehicle list. Accordingly, the OTA management platform obtains the first vehicle list and can initiate software upgrades for the vehicles in the first vehicle list. In other embodiments, unlike the above embodiments where the first vehicle list is determined based on the base station information connected to each vehicle, the OTA management platform can also determine that some vehicles are located in the same area and that the number of such vehicles reaches a threshold based on the location information (e.g., latitude and longitude) of each vehicle in the target vehicle list, thereby obtaining the first vehicle list.

[0050] Step 302: Obtain the vehicle-side wireless capability data and network-side wireless capability data for each vehicle.

[0051] In some embodiments, the vehicle's on-board wireless capability data may include: the vehicle's network behavior data and the vehicle's channel quality data.

[0052] In some embodiments, the vehicle's network behavior data may include, but is not limited to: the vehicle's call detail record (CDR) usage, the vehicle's APN activation frequency, and the vehicle's online duration.

[0053] Here, the call detail record (CDR) usage of a vehicle refers to the mobile data traffic (MB) consumed by the vehicle within a unit period. This parameter reflects the overall data service activity of the vehicle. In this embodiment, it is represented by D. The CDR usage of vehicle i is denoted as D_i.

[0054] Vehicle APN activation frequency: The number of times a vehicle establishes an APN connection within a unit period. Frequent activation / deactivation may indicate network instability or strong service intermittency. In this embodiment, it is denoted by F. The APN activation frequency of vehicle i is denoted as F_i.

[0055] Vehicle online duration: The total time (in minutes) during which the vehicle is in a communicable state within a unit period. This parameter directly reflects the size of the time window available for upgrades. In this embodiment, it is denoted by T. The online duration of vehicle i is recorded as T_i.

[0056] The embodiments of this application do not limit the specific duration of the unit cycle.

[0057] In some embodiments, the vehicle's channel quality data may include, but is not limited to, the vehicle's signal strength and the vehicle's signal-to-noise ratio.

[0058] The signal strength of the vehicle can be, for example, the vehicle's Reference Signal Received Power (RSRP), measured in dBm. A higher value indicates better wireless signal coverage. In this embodiment, it is represented by R. The signal strength of vehicle i is denoted as R_i.

[0059] The signal-to-noise ratio (SNR) of a vehicle, also known as the signal-to-interference-plus-noise ratio (SINR), is measured in dB. A higher SINR indicates a cleaner channel quality and higher transmission rate potential. In this embodiment, it is denoted by S. The SNR of vehicle i is denoted as S_i.

[0060] In some embodiments, the vehicle's network-side wireless capability data may include: the real-time load rate of the base station to which the vehicle is connected, the vehicle's cell-level channel quality, and the vehicle's user plane latency.

[0061] In this embodiment, the CPU utilization or bandwidth utilization of the base station can be used as the real-time load rate of the base station on the vehicle's connected base station, or the real-time load rate of the base station on the vehicle's connected base station can be calculated based on information such as the CPU utilization and bandwidth utilization of the base station. This parameter is the core of operator capability convergence and directly reflects the supply pressure on the network side. In this embodiment, it is represented by L.

[0062] Cell-level channel quality of the vehicle: The measurement results of the channel quality of the vehicle by the base station accessing the vehicle, such as the Channel Quality Indicator (CQI), are one of the indicators characterizing the cell-level channel quality of the vehicle. In this embodiment, the cell-level channel quality of the vehicle can be used as a network-side verification and supplement to the RSRP and SINR reported by the vehicle, improving data reliability. In this embodiment, it is represented by C. The cell-level channel quality of vehicle i is denoted as C_i.

[0063] User plane latency of a vehicle: The network latency (ms) during data transmission from the base station to the core network, which can be used to evaluate latency-sensitive services. In this embodiment, it is denoted by P. The user plane latency of vehicle i is denoted as P_i.

[0064] It should be noted that the above parameters are only examples. Vehicle-side wireless capability data and network-side wireless capability data may also include other parameters, such as latency, frequency band, base station cell ID, interference, etc., which will not be listed here.

[0065] Step 303: Calculate the vehicle's priority index based on the vehicle's on-board wireless capability data and the network's on-board wireless capability data.

[0066] Please refer to the instructions for this step. Figure 4 The illustrated embodiment will not be described in detail here.

[0067] Step 304: Sort the vehicles according to their priority index, and select the first target number of vehicles from the vehicle list, starting with the vehicle with the highest priority index, as the target vehicles.

[0068] For example, if the number of vehicles is 400 and the first target number is 100, then the 400 vehicles can be sorted in descending order of priority index, and the top 100 vehicles can be used as target vehicles.

[0069] Step 305: Upgrade the software of the target vehicle.

[0070] This method calculates the vehicle priority index based on the vehicle's on-board wireless capability data and the network's on-board wireless capability data. It then selects a first target number of vehicles with relatively high priority indices for software upgrades, thus achieving a paradigm shift from "one-sided scheduling" to "two-sided collaboration." This solves the systemic congestion problem of wireless resources caused by a lack of fine-grained scheduling in areas with high vehicle density. Furthermore, it overcomes the shortcomings of traditional solutions where "high-traffic vehicles" and "silent vehicles" compete for resources indiscriminately, and where static scheduling strategies cannot adapt to dynamic changes in vehicle online time. This achieves rational resource allocation for group efficiency, improves vehicle software upgrade efficiency, and ensures that "the right network resources are allocated to the right vehicles at the right time," significantly improving the overall upgrade throughput in high-density scenarios.

[0071] Moreover, this method can comprehensively analyze vehicle-side wireless capability data and network-side wireless capability data in densely populated vehicle scenarios, thereby accurately prioritizing vehicles requiring software upgrades and improving overall download efficiency. Furthermore, calculating the vehicle priority index based on the vehicle's network-side wireless capability data prevents OTA (Over-The-Air) updates from being unable to perceive the real-time network load of the operator's base stations in the vehicle's location, leading to a disconnect between scheduling decisions and actual network capacity, resulting in ineffective scheduling and significantly improving the utilization efficiency of wireless resources and the upgrade success rate. Additionally, linking vehicle software upgrades with both vehicle-side and network-side wireless capability data addresses the problem of disconnected channel quality parameters and vehicle network behavior parameters in complex wireless environments, hindering the construction of a unified quantitative model that comprehensively reflects the vehicle's upgradeability in real-world, dense network environments.

[0072] pass Figure 4 A possible implementation of step 303 is illustrated by example. Figure 4 As shown, step 303 may include: Step 401: Normalize the parameters included in the vehicle's on-board wireless capability data to obtain the vehicle's on-board normalized wireless capability data; and / or, normalize the parameters included in the vehicle's network-side wireless capability data to obtain the vehicle's network-side normalized wireless capability data.

[0073] This step can be considered a key bridge connecting data acquisition and index calculation. The purpose of normalizing the various parameters included in the vehicle-side wireless capability data and / or network-side wireless capability data is to eliminate the dimensional differences between different physical quantities (such as MB, count, minutes, dBm) and unify all parameters into a dimensionless, comparable numerical range.

[0074] In some embodiments, the OTA management platform may include a data preprocessing module to normalize the various parameters included in the vehicle-side wireless capability data and / or network-side wireless capability data. The specific implementation method of the normalization process is not limited in this application embodiment; the following example illustrates the normalization process using the min-max normalization method.

[0075] Assuming the vehicle's on-board wireless capability data includes: vehicle call detail record (CDR) usage, vehicle APN activation frequency, vehicle online duration, vehicle signal strength, and vehicle signal-to-noise ratio (SNR), and the vehicle's network-side wireless capability data includes: base station real-time load rate, vehicle cell-level channel quality, and vehicle user plane latency, then for vehicle i, the normalization formulas for each parameter are as follows: D_norm_i = (D_i - D_min) / (D_max - D_min); F_norm_i = (F_i - F_min) / (F_max - F_min); T_norm_i = (T_i - T_min) / (T_max - T_min); R_norm_i = (R_i - R_min) / (R_max - R_min); S_norm_i = (S_i - S_min) / (S_max - S_min); L_norm_i = (L_i - L_min) / (L_max - L_min); C_norm_i = (C_i - C_min) / (C_max - C_min); P_norm_i = (P_i - P_min) / (P_max - P_min); Where D_norm_i represents the normalized call detail record (CDR) usage of vehicle i, F_norm_i represents the normalized APN activation frequency of vehicle i, T_norm_i represents the normalized online duration of vehicle i, R_norm_i represents the normalized signal strength of vehicle i, S_norm_i represents the normalized signal-to-noise ratio of vehicle i, C_norm_i represents the normalized cell-level channel quality of vehicle i, L_norm_i represents the normalized real-time load rate of the base station side of vehicle i, and P_norm_i represents the normalized user plane latency of vehicle i.

[0076] in, _max represents the maximum value of this parameter among all vehicles within the current statistical period. _min represents the minimum value of this parameter among all vehicles within the current statistical period. This represents D, F, T, R, S, C, L, or P. For example, D_max represents the maximum call detail record (CDR) usage among all vehicles in the current statistical period, and D_min represents the minimum CDR usage among all vehicles in the current statistical period. For instance, if there are 500 vehicles, then there will be 500 CDR usage records, meaning there are 500 CDR usage records. D_max represents the maximum CDR usage among these 500 CDR usage records in the current statistical period, and D_min represents the minimum CDR usage among these 500 CDR usage records in the current statistical period.

[0077] After normalization, the normalized parameters of vehicle i The value of _norm_i is within the range of [0, 1]. The larger the value, the more "superior" or "urgent" the performance is in that dimension.

[0078] Step 402: Calculate the vehicle's priority index based on the vehicle's vehicle-side normalized radio capability data and / or network-side normalized radio capability data.

[0079] In some embodiments, this step may further combine the vehicle's historical average upgrade rate to calculate the vehicle's priority index. In this case, this step may include: calculating the vehicle's priority index based on the vehicle's vehicle-side normalized radio capability data and / or network-side normalized radio capability data, and based on the vehicle's historical average upgrade rate.

[0080] The vehicle-side wireless capability data in step 401 includes: vehicle call detail record (CDR) usage, vehicle APN activation frequency, vehicle online duration, vehicle signal strength, and vehicle signal-to-noise ratio. The vehicle-side network wireless capability data includes: base station real-time load rate, vehicle cell-level channel quality, and vehicle user plane latency distance. In this step, when calculating the vehicle priority index based on the vehicle-side normalized wireless capability data, the network-side normalized wireless capability data, and the vehicle's historical average upgrade rate, the priority index of vehicle i can be calculated using the following formula, where vehicle i can be any vehicle in the vehicle list.

[0081] PF-OTA-E_i=[(α·D_norm_i+β·F_norm_i+γ·T_norm_i)·(δ·R_norm_i+ζ·S_norm_i +η·C_norm_i)] / [ (L_norm_i +ε)·(R_hist_i+μ)·(P_norm_i +ν) ]; Wherein, PF-OTA-E_i represents the priority index of vehicle i; R_hist_i represents the historical average upgrade rate of vehicle i; α, β, γ, δ, ζ, and η are weighting coefficients, and ε, μ, and ν are constants.

[0082] The above formula is explained as follows: Molecular component: Characterizes the vehicle's "upgrade potential and urgency".

[0083] (α · D_norm _i + β · F_norm _i + γ · T_norm_i): This is a comprehensive score of network behavior. It quantifies the upgrade needs of vehicle i. The higher the score, the more "need" and "suitable" vehicle i is to be upgraded within this period.

[0084] α, β, and γ are weighting coefficients that satisfy α + β + γ = 1. Initial values ​​can be set by expert experience and adaptively adjusted based on the vehicle's historical upgrades. See the relevant documentation for details. Figure 5 Step 307 in the illustrated embodiment.

[0085] (δ · R_norm_i + ζ · S_norm_i + η · C_norm_i): This is the overall channel quality score. It quantifies the quality of the vehicle's current wireless transmission environment; a higher score means a higher probability and efficiency of a successful upgrade.

[0086] δ, ζ, and η are weighting coefficients that satisfy δ + ζ + η = 1. Initial values ​​can be set by expert experience and adaptively adjusted based on the vehicle's historical upgrade history. See the relevant documentation for details. Figure 5 Step 307 in the illustrated embodiment.

[0087] The design of the molecules incorporates a "reward" mechanism, rewarding vehicles with urgent needs and favorable channel conditions.

[0088] The denominator represents the "cost and difficulty" of acquiring upgrade resources.

[0089] (L_norm_i + ε): This is the network-side load cost factor. L_norm is the normalized real-time load rate of the base station; a larger value indicates a busier base station. Placing this factor in the denominator means that when a base station is heavily loaded, the priority of all vehicles under that base station will be suppressed, thus avoiding further congestion on an already congested network and guiding traffic to idle base stations. ε is a very small constant (e.g., 1e-5) used to prevent the denominator from being zero.

[0090] (R_hist_i + μ): This is the historical rate fairness factor. R_hist is the vehicle's historical average upgrade rate (MB / s). Placing this factor in the denominator reflects the principle of "proportional fairness," preventing vehicles with consistently good channel quality from monopolizing resources for extended periods, while allowing vehicles with fewer historical upgrade opportunities (smaller R_hist) to receive relatively higher priority in this round, thus improving system fairness. μ is a very small constant set to avoid division by zero.

[0091] (P_norm_i + ν): This is the network transmission cost factor. User plane latency reflects the quality of the transmission link from the base station to the core network. Higher latency usually indicates higher load or poorer quality on the core network or backhaul link, reducing the efficiency and increasing the cost of large-volume OTA upgrades. Placing it in the denominator means that the priority of high-latency vehicles will be moderately suppressed, thus guiding traffic to choose a better transmission link path. ν is a very small constant set to avoid division by zero.

[0092] In the above formula, the numerator integrates normalized vehicle network behavior data (call detail record usage, APN frequency, online duration) and real-time channel quality data to characterize the urgency and potential efficiency of vehicle upgrades. The denominator innovatively incorporates normalized base station-side real-time load (L) and the vehicle's historical average upgrade rate (R_hist) to characterize the network cost of acquiring resources and system fairness. Thus, this algorithm structure cleverly balances efficiency (throughput) and fairness, and maximizes system-level resource utilization efficiency through responses to network load.

[0093] The vehicle priority index calculated in this application embodiment can be considered as a "proportional fair priority index (PF-OTA Index)". The calculation of this priority index depends on vehicle-side wireless capability data and network-side wireless capability data, which realizes accurate profiling and dynamic adjustment of the vehicle's upgradeable capabilities.

[0094] Furthermore, the calculation formula for the aforementioned priority index uses demand and quality as the numerator and cost and history as the denominator, thus integrating three dimensions: terminal behavior, air interface quality, and network load. This reflects a balance between fairness and efficiency, enabling a more accurate reflection of the vehicle's true upgrade capability and avoiding resource misallocation. Moreover, the weighting coefficients (α, β, γ, δ, ζ, η) in the calculation formula are not fixed values ​​but are dynamically optimized based on upgrade feedback through machine learning (such as reinforcement learning). This gives the software upgrade method in this embodiment the ability to learn, adapt, and evolve automatically, automatically adjusting for different regions and network configurations, maintaining high efficiency without manual intervention, thus forming a technological barrier.

[0095] The following provides an example of a possible implementation of step 305.

[0096] In the first embodiment, step 305 may include: the OTA management platform sending upgrade notification messages to the target vehicles respectively, the upgrade notification messages being used to notify the target vehicles to perform software upgrades.

[0097] Correspondingly, each target vehicle receives an upgrade notification message, can access the CDN server, download the software upgrade package from the CDN server, and complete the software upgrade.

[0098] Optionally, the OTA management platform can specify an upgrade time for the target vehicle. The upgrade notification message can also include the upgrade time, so each target vehicle can access the CDN server during the upgrade time, download the software upgrade package from the CDN server, and complete the software upgrade.

[0099] In the second embodiment, to improve the download speed of the software upgrade package for the target vehicle, the OTA management platform can request the network capability open platform to allocate guarantee resources for the target vehicle. These guarantee resources can be, for example, temporary QoS guarantee resources or network slicing resources, thereby enabling the target vehicle to download the software upgrade package through these guarantee resources and ensuring its download speed. In this case, step 305 may include: The OTA management platform sends upgrade notification messages to the target vehicles and sends resource requests to the network capability open platform. The resource requests are used to request the network capability open platform to allocate support resources for the target vehicles.

[0100] It should be noted that if the upgrade notification message includes the upgrade time, the resource request mentioned above can also include the upgrade time, so that the network capability open platform can allocate support resources to the target vehicle based on the upgrade time, ensuring time synchronization in resource allocation and software download.

[0101] In the third embodiment, where the OTA management platform in the above two embodiments may not directly notify the target vehicle to perform a software upgrade, but instead notify the target vehicle to perform a software upgrade through the TSP platform, then step 305 may include: The OTA management platform determines the upgrade time for the target vehicle; The OTA management platform sends the target vehicle's information and upgrade time to the TSP platform and the network capability open platform, respectively. This enables the TSP platform to notify the target vehicle to initiate a software upgrade at the upgrade time, and enables the network capability open platform to allocate support resources to the target vehicle based on the upgrade time.

[0102] This application does not limit how the TSP platform notifies the target vehicle to initiate a software upgrade during the upgrade time, or how the network capability open platform allocates support resources to the target vehicle based on the upgrade time.

[0103] It should be noted that after the target vehicle's software upgrade is completed, the network capability open platform can release the security resources allocated to the target vehicle, thereby enabling the reasonable scheduling and allocation of data transmission resources.

[0104] Figure 5 This is a schematic flowchart of a software upgrade method provided in an embodiment of this application. Figure 5 The illustrated embodiment is relative to Figure 3 In the embodiment shown, after step 305, the following steps 306 to 308 are also included.

[0105] Step 306: Receive upgrade-related data for the target vehicle.

[0106] The target vehicle upgrade-related data is used to record relevant data for this software upgrade of the target vehicle, such as: the upgrade result of the target vehicle (success or failure), the average download speed of the software upgrade package, the upgrade end time, etc.

[0107] Step 307: Adjust the weight coefficients in the priority index calculation formula based on the upgrade-related data of the target vehicle.

[0108] Taking the aforementioned priority index calculation formula as an example, the weight coefficients calculated in this step may include the aforementioned α, β, γ, δ, ζ, and η.

[0109] In some embodiments, the OTA management platform can calculate the target parameters for a batch of vehicle upgrades (i.e., a batch of target vehicles) based on the upgrade-related data of each target vehicle, input the target parameters into a preset weight coefficient calculation model, and adjust the corresponding weight coefficients in the priority index calculation formula based on the weight coefficients output by the weight coefficient calculation model.

[0110] The aforementioned target parameters may include, but are not limited to: software upgrade success rate, average download speed, and upgrade completion time. Specifically, the software upgrade success rate = number of target vehicles with successful upgrades / total number of target vehicles (i.e., the first target number); the average download speed can be the average of the average download speeds of the first target number of target vehicles; and the upgrade completion time can be the latest time among the upgrade completion times of the first target number of target vehicles.

[0111] The OTA management platform may have a pre-trained weight coefficient calculation model. The specific training method for this model is not limited in this embodiment. The input to the weight coefficient calculation model is the target parameters for upgrading a batch of vehicles, and the output is the weight coefficients in the priority index calculation formula. In some embodiments, the weight coefficient calculation model can be implemented using a machine learning model, such as a reinforcement learning model.

[0112] By performing this step, the OTA management platform can acquire self-learning and self-evolution capabilities, enabling the priority index calculation formula in the OTA management platform to adapt to the network and service characteristics of different regions and periods, thereby expanding the applicability of the software upgrade method in this application embodiment.

[0113] Step 308: The OTA management platform updates the first vehicle list based on the upgrade results of the target vehicle to obtain the second vehicle list.

[0114] Specifically, the OTA management platform can delete or mark vehicles that have successfully upgraded from the first vehicle list to obtain a second vehicle list. The second vehicle list records vehicles from the first vehicle list that have not yet successfully undergone software upgrades, including vehicles that have not undergone software upgrades and vehicles that were targeted for software upgrades but failed.

[0115] After obtaining the second vehicle list, the OTA management platform can use the second vehicle list as the first vehicle list in step 301, and continue to execute steps 302 and subsequent steps to calculate the priority index of each vehicle in the second vehicle list. Based on this, a second target number of target vehicles are selected as the second batch of vehicles for software upgrade. Then, steps 306 to 308 can be executed to adjust the weight coefficients in the priority index calculation formula according to the upgrade-related data of the second batch of vehicles, and update the second vehicle list to obtain the third vehicle list. The third vehicle list is used as the first vehicle list in step 301, and so on, so as to perform software upgrades on the vehicles in the first vehicle list in batches.

[0116] The first and second target quantities mentioned above can be the same or different. For example, the second target quantity can be less than the first target quantity to reduce network load and improve the overall success rate of vehicle OTA-based software upgrades.

[0117] This method can divide the vehicles in the first vehicle list into several batches for software upgrades, prioritizing the upgrade of vehicles with higher priority indices. Furthermore, the priority index calculation formula can be dynamically updated based on the upgrade-related data of each batch of vehicles, thereby dynamically updating the priority index of vehicles that have not yet been upgraded, achieving rolling scheduling.

[0118] Figure 6 This is another flowchart illustrating the software upgrade method provided in an embodiment of this application. This embodiment combines... Figure 2 The system architecture shown is used to illustrate the software upgrade method of this application embodiment. Figure 6 As shown, the method may include: Step 601: The OTA management platform receives a software upgrade request message sent by the TSP platform. The software upgrade request message includes: a first list of vehicles.

[0119] The software upgrade request message is used to request the OTA management platform to perform a software upgrade for the first vehicle in the first vehicle list.

[0120] Step 602: In response to the software upgrade request message, the OTA management platform sends a software upgrade package download start message to the TSP platform.

[0121] The software upgrade package download start message instructs the TSP platform to begin software upgrades for the first vehicle list.

[0122] Step 603: The TSP platform sends a reporting instruction message to each vehicle in the first vehicle list.

[0123] The reporting instruction message is used to instruct each vehicle to report its vehicle-side wireless capability data to the OTA management platform.

[0124] Step 604: In response to the reporting instruction message, each vehicle reports its own vehicle-side wireless capability data to the OTA management platform.

[0125] It should be noted that if the calculation of the vehicle's priority index in step 606 requires calculation based on the vehicle's historical average upgrade rate, then each vehicle can report its own historical average upgrade rate to the OTA management platform in this step.

[0126] In other embodiments, each vehicle may also report its own vehicle-to-vehicle wireless capability data to the TSP platform, and the TSP platform will forward the vehicle-to-vehicle wireless capability data of each vehicle to the OTA management platform.

[0127] Step 605: The OTA management platform obtains the network-side wireless capability data of each vehicle from the network capability open platform.

[0128] In some embodiments, the OTA management platform may send a first vehicle list to the network capability open platform; the network capability open platform obtains the network-side wireless capability data of each vehicle recorded in the first vehicle list based on the first vehicle list, and sends the network-side wireless capability data of each vehicle to the OTA management platform.

[0129] This application does not limit how the network capability open platform obtains the network-side wireless capability data of each vehicle.

[0130] Step 606: The OTA management platform calculates the priority index of each vehicle based on the vehicle-side wireless capability data and the network-side wireless capability data of each vehicle.

[0131] Step 607: The OTA management platform sorts the vehicles in the first vehicle list according to their priority index, and selects the first target number of target vehicles starting from the vehicle with the highest priority index.

[0132] Step 608: The OTA management platform pushes the list of vehicles to be upgraded to the TSP platform. The list of vehicles to be upgraded contains the number of target vehicles mentioned above.

[0133] Optionally, the OTA management platform can also push the upgrade time corresponding to the list of upgraded vehicles to the TSP platform to indicate the specific upgrade time of the target vehicles in the list.

[0134] Step 609: The TSP platform sends upgrade notification messages to each target vehicle based on the list of vehicles to be upgraded.

[0135] Optionally, if the TSP platform receives the upgrade time, the upgrade notification message may include the upgrade time.

[0136] Step 610: The OTA management platform sends a request for resource allocation to the network capability open platform.

[0137] The resource allocation request is used to request the allocation of support resources for each target vehicle in order to download the software upgrade package.

[0138] The resource allocation request can include a list of upgraded vehicles.

[0139] Optionally, if the OTA management platform pushes the upgrade time corresponding to the list of upgraded vehicles to the TSP platform, the resource allocation request can also include the upgrade time corresponding to the list of upgraded vehicles, so as to instruct the network capability open platform to allocate the security resources corresponding to the upgrade time.

[0140] Step 611: Each target vehicle downloads the software upgrade package from the CDN server using OTA technology and performs the software upgrade.

[0141] Step 612: Each target vehicle sends upgrade-related data to the OTA management platform.

[0142] Step 613: The OTA management platform adjusts the weight coefficients in the priority index calculation formula based on the upgrade-related data of each target vehicle, and updates the first vehicle list to obtain the second vehicle list.

[0143] After that, you can return to 606, recalculate the priority index of each vehicle in the second vehicle list, and select the next batch of vehicles that need to be upgraded with software. This will not be elaborated on here.

[0144] The software upgrade method in this application aims to address the inherent defects exposed in high-density vehicle cluster areas. It provides an OTA-based software upgrade method that deeply integrates network-side wireless capability data and vehicle-side wireless capability data. Through a vehicle-network-cloud collaborative mechanism, it solves the software upgrade efficiency bottleneck in high-density vehicle cluster scenarios.

[0145] In the software upgrade method provided in this application embodiment, key status information of the network supply side, such as the real-time load rate of the base station, is introduced into the OTA scheduling system of the car manufacturer as a core decision variable through the operator's network capability open platform. This breaks down the data barrier between the car manufacturer and the operator, realizes the paradigm shift from "one-sided blind scheduling" to "two-sided collaborative scheduling", and builds an extremely high technical barrier.

[0146] Moreover, this method supports elastic deployment on vehicle manufacturers' cloud and operator edge computing (MEC) nodes, improving the flexibility, scalability and commercialization of the solution, making it adaptable to the IT architecture of different vehicle manufacturers and the infrastructure of operators.

[0147] Figure 7 A schematic diagram of a software upgrade device provided in an embodiment of this application is shown below. Figure 7 As shown, the device 700 may include: The module 710 is used to obtain a first vehicle list, which records multiple vehicles located in the same area; and to obtain vehicle-side wireless capability data and / or network-side wireless capability data for each vehicle. The calculation module 720 is used to calculate the priority index of the vehicle based on the vehicle-side wireless capability data and / or the vehicle-side network wireless capability data. Selection module 730 is used to sort the vehicles according to their priority index, and select a first target number of vehicles from the first vehicle list, starting with the vehicle with the highest priority index, as target vehicles; The upgrade module 740 is used to perform software upgrades on the target vehicle.

[0148] Optionally, the device 700 may further include a feedback optimization module for adjusting the weighting coefficients in the priority index calculation formula based on the upgrade-related data of each target vehicle.

[0149] Figure 7The apparatus provided in the illustrated embodiments can be used to execute the technical solutions of the method embodiments shown in this application, and its implementation principles and technical effects can be further referred to the relevant descriptions in the method embodiments.

[0150] The above should be understood Figure 7 The division of the various modules in the illustrated device is merely a logical functional division. In actual implementation, they can be fully or partially integrated into a single physical entity, or they can be physically separated. These modules can be implemented entirely in software via processing element calls; they can be fully implemented in hardware; or some modules can be implemented in software via processing element calls, while others are implemented in hardware. For example, the acquisition module can be a separate processing element or integrated into a chip in the terminal device. The implementation of other units is similar. Furthermore, these units can be fully or partially integrated together, or they can be implemented independently. For example, the aforementioned software upgrade device can be a chip or a chip module, or the aforementioned software upgrade device can be part of a chip or a chip module. During implementation, each step of the above method or each of the above units can be completed through integrated logic circuits in the hardware of the processor element or through software instructions.

[0151] This application also provides a chip module, including... Figure 7 The software upgrade device shown.

[0152] This application also provides a software upgrade system, including: Figure 7 The software upgrade device shown.

[0153] This application also provides an electronic device, including: a processor and a memory; wherein one or more computer programs are stored in the memory, and the one or more computer programs include instructions that, when executed by the processor, cause the electronic device to perform the method provided in this application.

[0154] This application also provides a computer-readable storage medium storing a computer program that, when run on a computer, causes the computer to execute the method provided in this application.

[0155] This application also provides a computer program product, which includes a computer program that, when run on a computer, causes the computer to perform the method provided in this application.

[0156] In this application embodiment, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent the existence of A alone, A and B simultaneously, or B alone. A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" and similar expressions refer to any combination of these items, including any combination of singular or plural items. For example, at least one of a, b, and c can represent: a, b, c, a and b, a and c, b and c, or a and b and c, where a, b, and c can be single or multiple.

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

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

[0159] In the several embodiments provided in this application, any function, if implemented as a software functional unit and sold or used as an independent product, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, essentially, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

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

Claims

1. A software upgrade method, characterized in that, include: Obtain a first vehicle list, which contains multiple vehicles located in the same area; Obtain vehicle-side wireless capability data and / or network-side wireless capability data for each of the vehicles; The priority index of the vehicle is calculated based on the vehicle's on-board wireless capability data and / or the vehicle's network-side wireless capability data. Based on the priority index of the vehicles, a first target number of vehicles are selected from the first vehicle list, starting with the vehicle with the highest priority index, as the target vehicles; The target vehicle undergoes a software upgrade.

2. The method according to claim 1, characterized in that, The vehicle-mounted wireless capability data includes at least one of the following parameters: call detail record (CDR) usage, APN activation frequency, online duration, signal strength, and signal-to-noise ratio; and / or, The network-side wireless capability data includes at least one of the following parameters: real-time load rate on the base station side, cell-level channel quality, and user plane latency.

3. The method according to claim 1 or 2, characterized in that, The step of calculating the vehicle's priority index based on the vehicle's on-board wireless capability data and / or the vehicle's network-side wireless capability data includes: The parameters included in the vehicle-side wireless capability data of the vehicle are normalized to obtain the vehicle-side normalized wireless capability data; and / or, the parameters included in the network-side wireless capability data of the vehicle are normalized to obtain the network-side normalized wireless capability data of the vehicle. The priority index of the vehicle is calculated based on the vehicle's vehicle-side normalized radio capability data and / or the vehicle's network-side normalized radio capability data.

4. The method according to claim 3, characterized in that, Also includes: Obtain the historical average upgrade rate for each of the aforementioned vehicles; The step of calculating the vehicle's priority index based on the vehicle's vehicle-side normalized radio capability data and / or the vehicle's network-side normalized radio capability data includes: The priority index of the vehicle is calculated based on the vehicle's vehicle-side normalized radio capability data and / or the vehicle's network-side normalized radio capability data, and based on the vehicle's historical average upgrade rate.

5. The method according to claim 4, characterized in that, Based on the vehicle-side normalized radio capability data and network-side normalized radio capability data of the first vehicle, and based on the vehicle's historical average upgrade rate, a priority index for the first vehicle is calculated, including: The priority index of the vehicle is calculated according to the following formula: PF-OTA-E_i=[(α·D_norm_i+β·F_norm_i+γ·T_norm_i)·(δ·R_norm_i+ζ·S_norm_i +η·C_norm_i)] / [ (L_norm_i +ε)·(R_hist_i+μ)·(P_norm_i +ν) ]; Wherein, PF-OTA-E_i represents the priority index of vehicle i; D_norm_i represents the normalized call detail record (CDR) usage of vehicle i; F_norm_i represents the normalized APN activation frequency of vehicle i; T_norm_i represents the normalized online duration of vehicle i; R_norm_i represents the normalized signal strength of vehicle i; S_norm_i represents the normalized signal-to-noise ratio of vehicle i; C_norm_i represents the normalized cell-level channel quality of vehicle i; L_norm_i represents the normalized real-time load rate of the base station side of vehicle i; R_hist_i represents the historical average upgrade rate of vehicle i; P_norm_i represents the normalized user plane latency of vehicle i; α, β, γ, δ, ζ, and η are weighting coefficients, and ε, μ, and ν are constants.

6. The method according to claim 1 or 2, characterized in that, The software upgrade of the target vehicle includes: Determine the upgrade time for the target vehicle; The information of the target vehicle and the upgrade time are sent to the TSP platform and the network capability open platform, respectively, so that the TSP platform notifies the target vehicle to start the software upgrade at the upgrade time, and the network capability open platform allocates support resources to the target vehicle at the upgrade time.

7. The method according to claim 5, characterized in that, Also includes: Receive upgrade-related data for the target vehicle; The weighting coefficients are adjusted based on the upgrade-related data of the target vehicle.

8. A software upgrade device, characterized in that, include: The module is used to obtain a first vehicle list, which records multiple vehicles located in the same area. Obtain vehicle-side wireless capability data and / or network-side wireless capability data for each of the vehicles; The calculation module is used to calculate the priority index of the vehicle based on the vehicle-side wireless capability data and / or the vehicle-side network wireless capability data. The selection module is used to sort the vehicles according to their priority index, and select a first target number of vehicles from the first vehicle list, starting with the vehicle with the highest priority index, as the target vehicles; The upgrade module is used to upgrade the software of the target vehicle.

9. An electronic device, characterized in that, include: Processor, memory; One or more computer programs are stored in the memory, the one or more computer programs including instructions that, when executed by the processor, cause the electronic device to perform the method of any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when run on a computer, causes the computer to perform the method described in any one of claims 1 to 7.

Images