Roadside device remote upgrading method under vehicle-road-cloud integrated architecture and related device

Abstract

The present disclosure provides a roadside device remote upgrading method under a vehicle-road-cloud integrated architecture and related devices, and relates to the technical fields of roadside devices, autonomous driving vehicles, cloud services and the like. The method comprises: obtaining historical true values of different dimension indicators of a sample roadside device at a historical time; performing normalization processing on the historical true values of each indicator, and determining the fluctuation degree of the corresponding indicator based on the normalized values; determining the processed value of the corresponding indicator based on the normalized value and the fluctuation degree of each indicator; calculating the system busy degree according to the preset contribution weight corresponding to each indicator and the processed value; taking the system busy degree at the historical time and the historical true value of the key indicator as the sample input, taking the system busy degree at the prediction time as the sample output, constructing a training sample set to train a busy degree prediction model, using the model to determine the prediction value of the system busy degree at each prediction time, and performing an upgrading operation in the time window determined based on the prediction value.

Description

Technical Field

[0001] This disclosure relates to the field of data processing technology, specifically to the fields of roadside equipment, autonomous vehicles, cloud services, etc., and particularly to a method, device, electronic equipment, computer-readable storage medium, and computer program product for remote upgrading of roadside equipment under a vehicle-road-cloud integrated architecture. Background Technology

[0002] With the development of the intelligent connected vehicle industry and smart transportation, the large-scale industrial application of intelligent connected vehicles is continuously promoted. In the vehicle-road-cloud integrated architecture consisting of intelligent connected vehicles, roadside equipment and cloud services, MEC (Multi-access Edge Computing) is the most core roadside infrastructure, which supports the operation of services such as vehicle-road cooperative autonomous driving, intelligent connectivity, digital twins, dynamic signal optimization, and smart transportation brain.

[0003] MECs are typically deployed at various intersections in cities to collect data and provide intelligent transportation and smart city-related services. With the construction of smart cities and the advancement of the "AI+" initiative, the number of intelligent connected intersections in China is gradually increasing. Summary of the Invention

[0004] This disclosure presents a method, apparatus, electronic device, computer-readable storage medium, and computer program product for remote upgrading of roadside equipment under a vehicle-road-cloud integrated architecture.

[0005] Firstly, this disclosure proposes a method for remotely upgrading roadside equipment under a vehicle-road-cloud integrated architecture, comprising: obtaining the historical true values ​​of different dimensions of the sample roadside equipment at historical times; normalizing the historical true values ​​of each indicator under each dimension, and determining the fluctuation degree of the corresponding indicator based on the calculated normalized values; determining the processed value of the corresponding indicator based on the normalized value and fluctuation degree of each indicator; calculating the system busyness of the sample roadside equipment at historical times according to the preset contribution weight and processed value corresponding to each indicator; and using the system busyness at historical times and the historical true values ​​of key indicators as the basis for further analysis. The system busyness is calculated from the historical true values ​​of each indicator at the predicted time after the historical time, and the system busyness is used as the sample output to construct a training sample set containing multiple sample pairs. Among them, the key indicators refer to some or all of the indicators used to describe information interaction with vehicles that can interact with information. The pre-set model is trained using the training sample set to obtain a busyness prediction model for predicting system busyness. The predicted value of the system busyness of the target roadside equipment at each predicted time is determined by the busyness prediction model, and the target roadside equipment is upgraded within the target time window determined based on the predicted value.

[0006] Secondly, this disclosure proposes a remote upgrade device for roadside equipment under a vehicle-road-cloud integrated architecture, comprising: a historical truth value acquisition unit configured to acquire historical truth values ​​of different dimensions of the sample roadside equipment at historical times; a normalization processing and volatility determination unit configured to normalize the historical truth values ​​of each indicator under each dimension and determine the volatility of the corresponding indicator based on the calculated normalized values; an indicator value processing unit configured to determine the processed value of the corresponding indicator based on the normalized value and volatility of each indicator; a system busyness determination unit configured to calculate the system busyness of the sample roadside equipment at historical times according to the preset contribution weight and processed value corresponding to each indicator; and a training sample set construction unit configured to... The system busyness at the historical moment and the historical true value of key indicators are used as sample inputs, and the system busyness calculated from the historical true value of each indicator at the prediction moment whose time series is after the historical moment is used as sample output, thus constructing a training sample set containing multiple sample pairs. Among them, key indicators refer to some or all of the indicators used to describe information interaction with vehicles that can interact with information. The model training unit is configured to train a preset model using the training sample set to obtain a busyness prediction model for predicting system busyness. The upgrade timing determination unit is configured to determine the predicted value of the system busyness of the target roadside equipment at each prediction moment through the busyness prediction model, and perform upgrade operations on the target roadside equipment within the target time window determined based on the predicted value.

[0007] Thirdly, embodiments of this disclosure provide an electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to implement the remote upgrade method for roadside equipment under the vehicle-road-cloud integrated architecture as described in the first aspect.

[0008] Fourthly, embodiments of this disclosure provide a non-transitory computer-readable storage medium storing computer instructions that enable a computer to perform a remote upgrade method for roadside equipment under the vehicle-road-cloud integrated architecture as described in the first aspect.

[0009] Fifthly, embodiments of this disclosure provide a computer program product including a computer program that, when executed by a processor, can implement the steps of the remote upgrade method for roadside equipment under the vehicle-road-cloud integrated architecture as described in the first aspect.

[0010] The remote upgrade solution for roadside equipment under the integrated vehicle-road-cloud architecture disclosed in this disclosure first obtains the historical true values ​​of different dimensions of indicators of sample roadside equipment at historical times, thus incorporating a sufficient number of parameters describing system busyness into the consideration. Then, by normalizing the historical true values ​​and calculating the degree of fluctuation, the processed values ​​of each indicator can ignore the different units used by each indicator and avoid the influence of fluctuation on the indicator values. Next, the processed values ​​of each indicator are weighted according to the contribution of different indicators to system busyness, thereby improving the accuracy of the calculated system busyness in describing the actual situation. The next step is to add the historical true values ​​of key indicators to the sample input, so that the model can better learn the actual contribution of these key indicators to the predicted value during the training phase. This improves the prediction accuracy of the trained busyness prediction model, enabling the model to determine the appropriate target time window for upgrading the target roadside equipment and execute the upgrade operation, ultimately reducing the risk of service interruption caused by roadside equipment performing upgrade operations.

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

[0012] Other features, objects, and advantages of this disclosure will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0013] Figure 1 This is an exemplary system architecture to which this disclosure can be applied;

[0014] Figure 2 A flowchart illustrating a method for remotely upgrading roadside equipment under a vehicle-road-cloud integrated architecture, as provided in this embodiment of the disclosure;

[0015] Figure 3 A flowchart illustrating a method for upgrading target roadside equipment using a traffic congestion prediction model, provided in this embodiment of the disclosure;

[0016] Figure 4 A flowchart illustrating a method for constructing a training sample set and upgrading target roadside equipment using a trained traffic congestion prediction model, provided in this embodiment of the disclosure;

[0017] Figure 5 This is a structural block diagram of a remote upgrade device for roadside equipment under a vehicle-road-cloud integrated architecture, provided in an embodiment of this disclosure.

[0018] Figure 6This is a schematic diagram of the structure of an electronic device suitable for performing a remote upgrade method for roadside equipment under a vehicle-road-cloud integrated architecture, as provided in an embodiment of this disclosure. Detailed Implementation

[0019] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding; these should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description. It should be noted that, unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other.

[0020] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0021] Figure 1 An exemplary system architecture 100 is shown, in which embodiments of the roadside equipment remote upgrade method, apparatus, electronic equipment, and computer-readable storage medium under the vehicle-road-cloud integrated architecture of this disclosure can be applied.

[0022] like Figure 1 As shown, system architecture 100 may include intelligent connected vehicles 101, roadside equipment 102, and cloud services 103. The network serves as the medium for providing communication links between the intelligent connected vehicles 101, roadside equipment 102, and cloud services 103. The network may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0023] The intelligent connected vehicle 101 can interact with the roadside equipment 102 via the network to receive or send messages, and the roadside equipment 102 can also interact with the cloud service 103 via the network to receive or send messages. Various applications for information communication between the intelligent connected vehicle 101, the roadside equipment 102, and the cloud service 103 can be installed. These applications include autonomous driving applications, system workload assessment applications, and instant messaging applications.

[0024] Cloud service 103 can provide various services through its built-in applications. Taking a system busyness assessment application that provides remote upgrade services to roadside equipment 102 as an example, cloud service 103 can achieve the following effects when running this system busyness assessment application: First, it obtains the historical true values ​​of different dimensions of the sample roadside equipment (e.g., a roadside equipment 102) at a historical time. Then, it normalizes the historical true values ​​of each indicator under each dimension and determines the fluctuation degree of the corresponding indicator based on the calculated normalized value. Next, it determines the processed value of the corresponding indicator based on the normalized value and fluctuation degree of each indicator. Then, according to the preset contribution weight and processed value corresponding to each indicator, it calculates the system busyness assessment value of the sample roadside equipment at a historical time. The system's busyness is assessed first. Then, the system busyness at historical time points and the historical true values ​​of key indicators are used as input samples. The system busyness calculated from the historical true values ​​of each indicator at the predicted time point (which is later than the historical time point) is used as the output sample. This constructs a training sample set containing multiple sample pairs. The key indicators refer to some or all of the indicators used to describe information interaction with vehicles capable of information interaction. Next, the pre-defined model is trained using the training sample set to obtain a busyness prediction model for predicting system busyness. Finally, the predicted system busyness of the target roadside equipment at each predicted time point is determined using the busyness prediction model, and the target roadside equipment is upgraded within the target time window determined based on the predicted values.

[0025] It should be noted that the historical true values ​​of different dimensions of the sample roadside equipment at historical moments can be obtained from the roadside equipment 102 in real time via the network, or they can be pre-stored locally on the cloud service 103 through various means. Therefore, when the cloud service 103 detects that this data has been stored locally (for example, when it starts processing previously retained pending tasks), it can choose to directly obtain this data from the local storage. In this case, the exemplary system architecture 100 may not include the intelligent connected vehicle 101 and the roadside equipment 102.

[0026] Since forming a training sample set and training a model requires a lot of computing resources and strong computing power, the remote upgrade method for roadside equipment under the vehicle-road-cloud integrated architecture provided in the subsequent embodiments of this disclosure is generally executed by a cloud service 103 with strong computing power and a lot of computing resources. Correspondingly, the remote upgrade device for roadside equipment under the vehicle-road-cloud integrated architecture is also generally set in the cloud service 103.

[0027] It should be understood that Figure 1The number of intelligent connected vehicles, roadside devices, and cloud services shown is merely illustrative. Depending on implementation needs, any number of intelligent connected vehicles, roadside devices, and cloud services can be included, with the cloud services typically built upon a foundation of multiple computers or servers.

[0028] Please refer to Figure 2 , Figure 2 A flowchart of a method for remotely upgrading roadside equipment under a vehicle-road-cloud integrated architecture provided in this disclosure embodiment, wherein process 200 includes the following steps:

[0029] Step 201: Obtain the historical true values ​​of different dimensions of the sample roadside equipment at historical times;

[0030] This step aims to improve the remote upgrade method for roadside equipment under the vehicle-road-cloud integrated architecture (e.g., the implementing entity). Figure 1 The cloud service 103 shown obtains the historical true values ​​of different dimensions of the sample roadside equipment at historical times. These different dimensions can include multiple indicators under various dimensions, including: traffic characteristic dimension, load characteristic dimension, service characteristic dimension, and network quality characteristic dimension. Multiple indicators under the traffic characteristic dimension include: vehicle flow, concurrent request count, data throughput, and average message packet length. Multiple indicators under the load characteristic dimension include: CPU utilization, memory utilization, GPU utilization, read / write speed, and bandwidth utilization. Multiple indicators under the service characteristic dimension include: the number of autonomous vehicles capable of information interaction, the number of connected vehicles, and the number of vehicles with traffic signal priority. Multiple indicators under the network quality characteristic dimension include: message latency, packet loss rate, and retransmission rate. It should be clarified that any indicator under any dimension can reflect the system busyness of the sample roadside equipment at a certain historical time. This system busyness, as a comprehensive concept, is used in this application to assess whether the current time is suitable for an upgrade operation (e.g., firmware, software data, hardware parameters, etc.), and the execution of this upgrade operation may affect the real-time services provided by the roadside equipment.

[0031] The core of the solution described in this step lies in the collection of historical data across multiple dimensions and indicators, aiming to comprehensively cover the key factors affecting the traffic volume of the roadside equipment (MEC) system. Specifically, the collection of historical true values ​​can be carried out from the following dimensions, each containing several specific indicators:

[0032] 1. Traffic characteristics dimension: Reflects the scale and intensity of data interaction between MEC, vehicles, and the cloud.

[0033] 1) Traffic flow: The total number of vehicles passing through the MEC coverage area per unit time, reflecting basic communication needs; 2) Concurrent requests: The number of vehicle or cloud requests processed by MEC simultaneously, directly related to instantaneous load pressure; 3) Data throughput: The total volume of data sent and received by MEC per unit time (e.g., MB / s), measuring data transmission load; 4) Average message packet length: The average number of bytes in a single interactive message, affecting network bandwidth and parsing efficiency.

[0034] 2. Load characteristics dimension: depicts the real-time consumption status of MEC hardware resources.

[0035] 1) CPU utilization: The proportion of processor usage. High utilization may lead to task backlog. 2) Memory utilization: The usage of running memory. Exceeding the limit may trigger frequent garbage collection or lag. 3) GPU utilization (if image processing is supported): Such as the computing power requirements of video analysis tasks. 4) Read and write speed: The data access speed of storage devices (such as solid-state drives), which affects the efficiency of log and cache processing. 5) Bandwidth utilization: The ratio of the actual bandwidth used by the network interface to the total bandwidth, reflecting the saturation level of the communication link.

[0036] 3. Business characteristics dimension: Focusing on core business scenarios involving vehicle interaction, which directly affect service priority and resource allocation.

[0037] 1) Number of autonomous vehicles capable of information exchange: The number of vehicles requiring high reliability and low latency communication; its increase or decrease significantly affects system pressure.

[0038] 2) Number of connected vehicles capable of information exchange: The total number of ordinary connected vehicles. Although the demand per vehicle is low, the scale effect is obvious.

[0039] 3) Number of traffic signal priority vehicles that can exchange information (such as ambulances, fire trucks, and buses): These vehicles need to coordinate with traffic lights in real time, which involves complex business logic and low fault tolerance.

[0040] 4. Network quality characteristics dimension: assess the stability of the communication link. Deterioration may lead to retransmission or timeout, indirectly increasing the load.

[0041] 1) Message delay: End-to-end delay from sending to receiving; delay fluctuations may reflect network congestion. 2) Packet loss rate: The proportion of data packets lost during transmission; a high packet loss rate requires triggering a retransmission mechanism. 3) Retransmission rate: The frequency of repeated transmission of data packets due to packet loss or errors, which consumes additional resources.

[0042] To obtain the historical true values ​​of the aforementioned metrics, in practice, these values ​​can be obtained through a combination of MEC's ​​built-in sensors (such as CPU / memory monitoring), network probes (such as packet loss detection), business logs (such as vehicle connection records), and cloud-based collaborative statistics (such as regional traffic flow). Depending on business needs, data can be collected at the second level (such as CPU utilization), the minute level (such as traffic flow), or event-triggered events (such as a sudden increase in retransmission rate), ensuring time sequence alignment. Furthermore, the raw data needs to be cleaned (outliers removed), completed (interpolation to handle missing points), and timestamped to construct a coherent historical sequence. The correlation between key metrics should also be considered; for example, the "number of autonomous vehicles" in the business characteristic dimension may be strongly correlated with the "number of concurrent requests" in the traffic dimension, requiring differentiation of their independent contributions during subsequent weighted calculations.

[0043] Step 202: Normalize the historical true value of each indicator under each dimension, and determine the fluctuation degree of the corresponding indicator based on the calculated normalized value;

[0044] Building upon step 201, this step aims to have the aforementioned executing entity normalize the historical true values ​​of each indicator under each dimension to eliminate potential dimensional differences between different indicators. Based on the calculated normalized values, the degree of fluctuation of the corresponding indicators is determined to fully consider the impact of volatility on the value magnitude. In other words, the core objective of this step is to eliminate dimensional differences between indicators and quantify their fluctuation characteristics, providing standardized and stable input for subsequent calculations of system workload.

[0045] Normalization refers to normalizing the historical true value sequence of all indicators in each dimension (such as "traffic flow" in the traffic characteristic dimension, "CPU utilization" in the load characteristic dimension, etc.) and mapping them to a uniform scale (such as the [0,1] interval or a standard normal distribution). For example, the following methods can be used: 1) Min-Max Normalization: linearly transforms the original value to [0,1], suitable for situations where the indicator boundary is clear (such as the theoretical upper limit of 100% for CPU utilization); 2) Z-score Standardization: adjusts based on mean and standard deviation, suitable for indicators with extreme values ​​(such as sudden high traffic flow); 3) Logarithmic Transformation: compresses the numerical range of long-tailed distributed indicators (such as data throughput) to reduce the influence of skewness. In summary, the normalization process can choose the method according to the characteristics of the indicator. For example, the "number of autonomous vehicles" in the business dimension may follow a Poisson distribution, which is suitable for quantile normalization.

[0046] The volatility calculation is based on a normalized indicator sequence. Volatility is analyzed using a sliding window (e.g., the past hour). Methods include: 1) Standard deviation / variance: directly measures the dispersion of values ​​within the window, suitable for stationary indicators (e.g., bandwidth utilization); 2) Coefficient of variation (standard deviation / mean): a relative volatility measure, suitable for indicators with mean changes (e.g., message latency); 3) Local range (maximum value minus minimum value within the window): quickly captures sudden fluctuations (e.g., a sudden increase in packet loss rate). Specifically, the window size needs to match the indicator characteristics: short windows (e.g., 5 minutes) are suitable for high-frequency volatility indicators (e.g., concurrent request count), long windows (e.g., 1 day) are suitable for periodic indicators (e.g., peak traffic flow), and for non-stationary sequences (e.g., trending GPU utilization), trend removal is necessary before calculating volatility to minimize misjudgment. Furthermore, the volatility calculation can be adjusted based on business logic: for example, if the "number of vehicles with priority at traffic signals" in the business feature dimension fluctuates drastically (e.g., sudden emergencies), its volatility may need to be amplified because it has a greater instantaneous impact on system load.

[0047] Step 203: Determine the processed value of the corresponding indicator based on the normalized value and volatility of each indicator;

[0048] Building upon step 202, this step aims to have the aforementioned executing entity determine the processed value of each indicator based on its normalized value and volatility. In other words, the purpose of this step is to generate a more stable processed value that better reflects the true load state of the system by combining the normalized indicator value with its volatility, thereby avoiding misjudgments caused by instantaneous fluctuations or noise.

[0049] The normalized index values ​​eliminate dimensional differences, making different indicators comparable and laying the foundation for subsequent weighted calculations of system workload. The degree of fluctuation reflects the stability of the index within a historical window. Highly volatile indicators (such as sudden traffic spikes or instantaneous CPU peaks) may interfere with system workload calculations; therefore, adjustments based on the degree of fluctuation are needed to smooth out the impact of abnormal fluctuations. Based on this, this step determines that the processed values ​​will have the following effects:

[0050] 1) Suppress the impact of highly volatile indicators: For highly volatile indicators (such as occasional sudden increases in network packet loss rate), the contribution of their normalized values ​​can be reduced to avoid excessive impact of a single outlier on system busyness. For example, if an indicator has a high degree of volatility, its processed value can be reduced by a certain proportion based on the normalized value, so that its weight is relatively reduced in the weighted calculation; 2) Preserve the stability of low-volatile indicators: For indicators with small volatility (such as memory usage rate, which is usually relatively stable), their normalized values ​​can be directly or slightly adjusted as processed values ​​to ensure that they stably represent the system state; 3) Dynamic adjustment mechanism: The degree of volatility may change over time (such as the different fluctuation patterns of traffic flow during morning and evening peak hours), so the calculation of processed values ​​needs to support dynamic adaptation, such as using a sliding window to update the degree of volatility in real time and adjusting the impact of the normalized values ​​accordingly.

[0051] Furthermore, considering that different metrics have varying sensitivities to system load, for example, if the "number of autonomous vehicles" in the business dimension fluctuates significantly, it may require careful handling because it is directly related to high-priority tasks; while if the "average message packet length" in the traffic dimension fluctuates significantly, it may have a smaller impact on the system and can be appropriately suppressed. In extreme cases (such as a metric fluctuating drastically over a long period), it is necessary to set an upper or lower limit for the degree of fluctuation to prevent the processed value from deviating excessively from the true state.

[0052] Step 204: Calculate the system busyness of the sample roadside equipment at historical time based on the preset contribution weight and processed value corresponding to each indicator;

[0053] Building upon step 203, this step aims to have the aforementioned executing entity calculate the system busyness of the sample roadside equipment at a historical time based on the preset contribution weights and processed values ​​corresponding to each indicator. In other words, the purpose of this step is to comprehensively evaluate the overall load status of the roadside equipment at a specific historical time by fusing the processed values ​​of multi-dimensional indicators according to their preset contribution weights to generate a comprehensive and quantitative system busyness indicator.

[0054] The "preset contribution weight" is an importance coefficient pre-set for each indicator based on domain knowledge and historical data analysis. It reflects the differentiated impact of different indicators on the overall system busyness. For example, indicators directly related to core vehicle interaction services (such as "the number of autonomous vehicles capable of information interaction") are usually assigned higher weights because their fluctuations have a more critical impact on the real-time performance and reliability of the system service; while some basic resource indicators (such as "read / write rate") may have relatively lower weights. These weights are not fixed and can be iteratively optimized based on actual operating results after system deployment. The "processed value" is the output of the previous step. It is a standardized value obtained by normalizing the original historical true value of the indicator and combining it with its fluctuation degree. This value not only eliminates the dimensional differences between different indicators but also smooths out the noise caused by instantaneous fluctuations to a certain extent, and better represents the "steady-state" load level of the indicator at that moment. The specific operation of "calculating system busyness" adopts a weighted summation model. The processed value of each indicator is multiplied by its corresponding preset contribution weight, and then the weighted results of all indicators are summed to finally obtain a scalar value, that is, the system busyness at that historical moment. This value is a comprehensive metric, and its value directly represents the overall load level of the device at that moment: the higher the value, the busier the system, the more strained the resources, and the greater the risk of service interruption; conversely, the lower the value, the more idle the system.

[0055] It's important to note that allocating contribution weights requires a high degree of expertise and must be closely aligned with the specific business scenarios of the roadside equipment. For example, in an environment primarily focused on providing high-precision map updates, the weight of metrics related to "network quality characteristics" (such as "message latency") will be significantly increased; while in a scenario primarily handling a large volume of vehicle status messages, metrics related to "traffic characteristics" (such as "concurrent request count") will play a more significant role. This weighting design, tailored to the specific needs of the scenario, ensures that the final calculated system busyness is not a simple numerical value, but a reliable indicator that accurately depicts the actual operating status of the equipment under current business pressure, thereby providing high-quality, highly reliable labeled data for subsequent model training.

[0056] Step 205: Use the system busyness at historical time points and the historical true values ​​of key indicators as sample inputs, and use the system busyness calculated from the historical true values ​​of each indicator at the prediction time point after the historical time point as sample outputs to construct a training sample set containing multiple sample pairs.

[0057] Building upon step 204, this step aims to construct a training sample set containing multiple sample pairs by having the aforementioned executing entity use the historical system busyness at historical time points and the historical ground values ​​of key indicators as sample inputs, and calculate the system busyness at the prediction time point (which is later than the historical time point) using the historical ground values ​​of each indicator as sample outputs. In other words, the purpose of this step is to prepare high-quality, strongly correlated supervised learning data for the subsequent training of the busyness prediction model. Here, the key indicators refer to some or all of the indicators used to describe information interaction with vehicles capable of information interaction, such as at least one of the following indicators: traffic flow, number of concurrent requests, CPU utilization, and number of autonomous vehicles.

[0058] Among them, "system busyness at a historical moment" is a comprehensive scalar value, which is part of the sample input. It is obtained by weighted summation of the processed values ​​of all dimensions of indicators at that historical moment, and represents the overall load status of the device at that moment. This value is the basis for the model to understand the historical "context" or "state baseline" of the system.

[0059] The "historical true values ​​of key metrics" is another core part of the sample input. This specifically refers to the raw values ​​(unnormalized or otherwise processed) of metrics that directly describe information interaction with vehicles, such as the "number of autonomous vehicles capable of information interaction," the "number of connected vehicles," and network quality metrics like "message latency" and "packet loss rate." A key design is to include the true values ​​of these key metrics (rather than their processed values ​​or derived busyness) alongside the system busyness as input. This is equivalent to providing the model with an overall state summary (busyness) while simultaneously providing raw, detailed data on the core driving factors most likely to influence future states, significantly enhancing the model's input information.

[0060] The "system busyness at the predicted time" is output as a sample, and its calculation method is exactly the same as the historical busyness in the input: it is obtained by using the historical true values ​​of each indicator collected at the predicted time (a time point after the historical time), through the same preprocessing process (normalization, calculation of volatility, generation of processed values), and weighted summation. This value represents the target that we hope the model will predict at that specific time in the future.

[0061] Building upon the above, constructing the training sample set involves pairing each historical time t with a future predicted time t+Δt, forming a sample pair. The input is the system busy level and the true value of key indicators at time t, and the output is the system busy level at time t+Δt. By traversing historical data, a massive number of such sample pairs can be constructed.

[0062] In practical terms, the selection of "key indicators" in the sample can be strictly limited to indicators strongly correlated with vehicle interaction, because the model needs to learn from this raw data how interaction behavior specifically drives changes in system state. The time interval Δt can be set as a hyperparameter, which needs to match the business scenario and upgrade operation time. For example, if the upgrade requires a 5-minute idle window, then Δt may be set to 5 minutes or 10 minutes, allowing the model to learn to predict the busy level 5-10 minutes later. All the true values ​​of the indicators used to calculate the output (predicted busy level) must be real observations that exist in the historical record, and must not contain any information from the future, to ensure the rigor of the training process. Finally, this constructed sample set, containing a large number of "historical state -> future state" mapping relationships, will be used to train the model, enabling it to learn to accurately predict future system busy levels based on the current system busy level and key real-time interaction indicators.

[0063] Step 206: Train the model using the preset model in the training sample set to obtain a busyness prediction model for predicting system busyness.

[0064] Building upon step 205, this step aims to train a pre-defined model using the training sample set, as described above, to obtain a busyness prediction model for predicting system busyness. In other words, through a data-driven approach, the model learns to accurately infer future patterns of system busyness changes from historical system states and real-time interaction data. This pre-defined model can be any pre-trained model capable of achieving a similar purpose, such as LightGBM (Light Gradient Boosting Machine).

[0065] Step 207: Determine the predicted system busyness of the target roadside equipment at each predicted time using the busyness prediction model, and perform upgrade operations on the target roadside equipment within the target time window determined based on the predicted values.

[0066] Building upon step 206, this step aims to have the aforementioned executing entity determine the predicted system load of the target roadside equipment at each predicted time using a load prediction model, and then perform upgrade operations on the target roadside equipment within the target time window determined based on the predicted values. In other words, the purpose of this step is to proactively identify periods of low system load using a trained prediction model, thereby minimizing the risk of disruption to vehicle-road cooperative services caused by the upgrade operation.

[0067] In this step, the "busyness prediction model" serves as the core prediction engine. Its input consists of two types of real-time data collected from the target roadside equipment: first, the current system busyness calculated using real-time indicators (generated using the same weighted summation logic as in the training phase); and second, the true values ​​of key vehicle interaction-related indicators (such as the number of autonomous vehicle connections and message latency). Based on these inputs, the model outputs predicted system busyness values ​​for multiple consecutive future prediction points (e.g., every minute within the next 30 minutes), forming a prediction curve. These predicted values ​​essentially reflect the model's ability to extrapolate the future load state of the equipment, and their accuracy depends on the thorough learning of historical state evolution patterns during the training phase.

[0068] The determination of the target time window is a dynamic decision-making process based on the prediction curve. The decision-making system scans the prediction curve, looking for time periods that meet the following conditions: 1) the predicted value is consistently below a safety threshold (this threshold is usually set according to equipment performance and service level agreements; for example, a busy level ≤ 0.3 indicates low risk); 2) the time period is long enough to cover the upgrade operation time (if the upgrade takes 5 minutes, then at least 5 minutes of continuous low predicted values ​​are required); 3) the time period has high stability (avoiding time periods that meet the threshold but fluctuate drastically). The optimal window is usually the continuous time period with the lowest and most stable busy level in the prediction curve, such as the low traffic hours late at night or specific intervals during off-peak hours.

[0069] The "Execute Upgrade Operation" is the final action triggered within the target window. To ensure security, the system can perform secondary verification before the window opens: 1) Real-time busy level verification to confirm that the current actual busy level matches the prediction; 2) Vehicle interaction status check to ensure that no high-priority vehicles (such as ambulances) are communicating; 3) Rollback contingency plan readiness to quickly restore service in case of upgrade failure or sudden high load. During the upgrade process, the system continuously monitors the actual busy level, and immediately pauses or rolls back if it exceeds expectations. In addition, the upgrade command can be encrypted using a security protocol to ensure upgrade package verification and version compatibility in collaboration with the cloud.

[0070] Furthermore, when determining the timing of upgrades, regional coordination should also be considered. For example, the upgrade windows of adjacent MECs should be staggered to avoid the impact of multiple devices being upgraded simultaneously on regional service continuity.

[0071] The remote upgrade method for roadside equipment under the vehicle-road-cloud integrated architecture provided in this disclosure first obtains the historical true values ​​of different dimensions of the sample roadside equipment at historical times, thus incorporating a sufficient number of parameters describing system busyness into the consideration. Then, by normalizing the historical true values ​​and calculating the degree of fluctuation, the processed values ​​of each indicator can ignore the different units used by each indicator and avoid the influence of fluctuation on the indicator values. Next, the processed values ​​of each indicator are weighted according to the contribution degree of different indicators to system busyness, thereby improving the accuracy of the calculated system busyness in describing the actual situation. The next step is to add the historical true values ​​of key indicators to the sample input, so that the model can better learn the actual contribution of these key indicators to the predicted value during the training phase. This improves the prediction accuracy of the trained busyness prediction model, enabling the model to determine a suitable target time window for upgrading the target roadside equipment and execute the upgrade operation, ultimately reducing the risk of service interruption caused by the roadside equipment performing upgrade operations.

[0072] Based on the above embodiments, this embodiment also provides a specific implementation method for step 202, including:

[0073] For each indicator under each dimension, the historical true values ​​within a preset time period before the historical moment are obtained, and the maximum and minimum true values ​​are determined based on the historical true values ​​within the preset time period before the historical moment. Based on the value range determined by the maximum and minimum true values, the historical true values ​​at the historical moment are normalized to obtain the normalized values ​​of the corresponding indicators.

[0074] For each indicator under each dimension, the standard deviation between the normalized values ​​of the corresponding indicator within a preset time window is used to determine the degree of fluctuation of the corresponding indicator; the preset time window is determined based on the actual business duration of the sample roadside equipment.

[0075] The solution provided in this embodiment first requires obtaining the original true value sequence within a preset time period before the historical moment for each indicator of each dimension (such as "vehicle flow" in the traffic characteristic dimension and "CPU utilization" in the load characteristic dimension). This preset time period needs to be dynamically set according to the actual business characteristics of the roadside equipment. For example, in scenarios with obvious traffic peaks, 24 hours may be selected to cover the entire period, while in a steady-state business environment, only 1 hour of data may be needed. Based on this sequence, the maximum and minimum true values ​​of the indicator in that time period are determined, forming its value range (maximum value - minimum value). Then, the true values ​​of the historical moment are normalized by linearly mapping to the [0,1] interval. For example, if the current vehicle flow true value is between the minimum of 100 vehicles and the maximum of 1000 vehicles in that time period, it is mapped to the corresponding proportional value. This normalization method based on the extreme values ​​of a dynamic time window can adapt to the natural fluctuation range of different indicators and avoid the sensitivity imbalance caused by fixed thresholds.

[0076] For calculating volatility, an independent preset time window can be defined for each indicator (e.g., a 30-minute window if the business cycle is 5 minutes). Within this window, all normalized values ​​are extracted and their standard deviation is calculated to quantify the indicator's stability. For example, if the normalized value of CPU utilization fluctuates wildly within the window, the standard deviation is high, reflecting strong volatility; while if memory utilization changes smoothly, the standard deviation is low, indicating good stability. The advantage of standard deviation as a measure of volatility lies in its mathematical clarity, directly reflecting the relative dispersion after normalization. The business duration setting can be adjusted based on the indicator's characteristics: high-frequency indicators (e.g., requests per second) are suitable for short windows to capture instantaneous fluctuations, while low-frequency indicators (e.g., the number of connected vehicles per hour) require long windows to avoid misjudging trends as volatility. The entire processing must ensure real-time performance, typically using a sliding window to incrementally calculate extreme values ​​and standard deviations, ensuring the system can dynamically adapt to changes in business load. The final generated normalized values ​​and volatility levels retain the original variation characteristics of the indicators while eliminating interference from units and absolute values, providing standardized input for subsequent weighted fusion.

[0077] Based on the above embodiments, this embodiment also provides a specific implementation method for step 203, including:

[0078] For each indicator in each dimension, a first weight corresponding to the normalized value of the corresponding indicator at a historical time and a second weight corresponding to the degree of fluctuation of the corresponding indicator at a historical time are determined.

[0079] For each indicator under each dimension, the normalized value obtained by weighting the first weight of the corresponding indicator with the fluctuation level obtained by weighting the second weight will be used to determine the processed value of the corresponding indicator.

[0080] The solution provided in this embodiment balances the real-time load representation and historical fluctuation characteristics of indicators through a dual-weighting mechanism, thereby generating processed values ​​that better reflect the true state of the system. In specific implementation, firstly, two dynamic weights need to be determined for each indicator in each dimension (such as "number of autonomous vehicles" in the business characteristic dimension or "packet loss rate" in the network quality dimension): The first weight is specifically used to weight the normalized value of the indicator at the current historical moment. Its setting principle is to prioritize core indicators that contribute significantly to system busyness; for example, indicators directly related to vehicle safety communication will be assigned a higher first weight. The second weight is specifically used to weight the degree of fluctuation of the indicator. Its setting logic is to suppress the interference of highly volatile indicators. For example, if the network retransmission rate fluctuates drastically, its second weight will be reduced to weaken the impact of outliers. The specific values ​​of these two weights are usually based on domain knowledge presets, but can also be dynamically adjusted through historical data analysis. For example, the higher the correlation coefficient between an indicator and system failures in the past week, the higher its first weight will be. After the weights are assigned, the processed value of each indicator is generated by multiplying the normalized value by the first weight and the volatility by the second weight, and then merging the two weighted results in a linear or non-linear manner (such as adding or taking the maximum value).

[0081] It should be clarified that the advantage of this dual-weighting mechanism lies in the following: for important indicators with high stability (such as stable CPU utilization), the high first weight ensures that it dominates the processed value; while for indicators with large fluctuations but critical value (such as a sudden increase in the number of autonomous vehicles), appropriately reducing the second weight can preserve their importance while smoothing out abnormal fluctuations. In actual business operations, the dynamic adaptability of the weights also needs to be considered. For example, the weight of traffic flow characteristic indicators can be temporarily increased during morning and evening peak traffic periods, or the weight of network quality indicators can be increased when the network is congested. The final processed value includes both the real-time load information of the indicator and its historical stability characteristics, providing an interference-resistant and business-sensitive data foundation for the comprehensive calculation of system busyness. This allows subsequent upgrade decisions to more accurately identify the true load status of the system and avoid misjudgments caused by instantaneous fluctuations of a single indicator.

[0082] To deepen your understanding of the specific process of the solution provided in step 206, please refer to... Figure 3 , Figure 3 A flowchart of a method for upgrading target roadside equipment using a traffic congestion prediction model, provided as an embodiment of this disclosure, is provided, wherein process 300 includes the following steps:

[0083] Step 301: Obtain the current values ​​of different dimensions of the target roadside equipment at the current moment;

[0084] This step aims to collect the current values ​​of various metrics of the target device in real time (such as CPU utilization, number of connected vehicles, packet loss rate, etc.). These data are acquired through the device's built-in sensors and network probes and updated at a preset frequency (such as second-level or minute-level).

[0085] Step 302: Calculate the system busyness of the target roadside equipment at the current moment based on the current values ​​of each indicator;

[0086] This step aims to generate a comprehensive load indicator of the current system busyness by summing the current values ​​of each indicator after normalization, fluctuation suppression, and other processing, based on the same weighted calculation logic as in the training phase.

[0087] Step 303: Input the current system busyness of the target roadside equipment and the current values ​​of key indicators into the busyness prediction model to obtain the predicted values ​​of the system busyness of the target roadside equipment at each prediction time.

[0088] This step aims to input the raw values ​​of the current busyness and key vehicle interaction indicators (such as the number of autonomous vehicles, message latency, etc.) into a pre-trained busyness prediction model. Based on learning the evolution of historical states, the model outputs a sequence of system busyness prediction values ​​for multiple consecutive prediction moments in the future (such as every minute in the next 30 minutes).

[0089] Step 304: Compare the predicted values ​​of the system busyness of the target roadside equipment at different prediction times with the busyness thresholds set in advance for the target roadside equipment.

[0090] This step aims to compare these predicted values ​​with preset busyness thresholds (usually set according to device performance and service level agreements, such as a busyness threshold of ≤0.3 as a safety threshold) in real time, and filter out all predicted times that are below the threshold.

[0091] Step 305: Among all predicted times with predicted values ​​less than the busyness threshold, determine the target time window that meets the upgrade duration requirement;

[0092] This step further imposes business constraints based on step 304. For example, it may first require that the duration of consecutive low load periods must cover the time required for a complete upgrade operation (e.g., if the upgrade takes 5 minutes, then at least 5 consecutive low forecast values ​​are required). Secondly, it will check the stability of the period (e.g., remove periods that are below the threshold but fluctuate drastically). Finally, it will determine the target time window that best meets the conditions: usually, the period with the lowest forecast value and the longest duration is selected to reserve a safety margin.

[0093] Step 306: Control the target roadside equipment to perform upgrade operations within the target time window.

[0094] This step involves multiple verifications before the upgrade: for example, real-time verification of whether the actual current traffic volume still matches the prediction, checking if high-priority vehicles (such as ambulances) are communicating, and confirming the integrity and version compatibility of the upgrade package. After verification, the upgrade command is sent through an encrypted channel, and the system status is continuously monitored during the upgrade process. If an abnormal increase in traffic volume or service anomaly is detected, a rollback mechanism is immediately triggered. The entire process achieves low-latency processing through edge computing devices, uses streaming computing for high-frequency indicators (such as CPU utilization) to ensure real-time performance, and supports regional collaboration strategies to prevent adjacent devices from upgrading simultaneously.

[0095] The essence of the solution provided in this embodiment is to transform traditional fixed-time upgrades into data-driven dynamic intelligent decision-making. Through accurate prediction and multiple protection mechanisms, it achieves efficient operation and maintenance of equipment while ensuring service continuity.

[0096] It should be noted that steps 304-306 provided in this embodiment do not depend on the solutions provided in steps 301-303 as the only basic prerequisite solutions. Conversely, the subsequent solutions of the prerequisite solutions provided in steps 3201-303 do not necessarily have to be the solutions specifically provided in steps 304-306. This embodiment exists only as an accumulation of preferred implementations of the two higher-level solutions.

[0097] There may be multiple implementation methods for step 305 in process 300, depending on the specific requirements of the upgrade time. Two different specific implementation methods are given below:

[0098] Method 1: In response to the existence of multiple time windows that all meet the upgrade duration requirements, determine the average value of the predicted system busyness for each time window; and determine the time window with the smallest average value as the target time window.

[0099] This approach employs the principle of minimizing load. When the system detects that multiple consecutive time periods (such as 10:00-10:05 and 11:30-11:35) all meet the upgrade duration requirement (such as 5 minutes), it calculates the arithmetic mean of the busyness of all predicted times within each window. For example, if the average of the 5 predicted values ​​in the first window is 0.25 and that in the second window is 0.18, then the 11:30-11:35 time period with the lower average value is selected for the upgrade. This strategy directly uses system load as the basis for decision-making, ensuring that the equipment is in the most idle state during the upgrade.

[0100] Method 2: In response to the existence of multiple time windows that all meet the upgrade duration requirements, determine the number of associated roadside devices scheduled to perform the upgrade operation in each time window; where associated roadside devices refer to other roadside devices that are associated with the target roadside device in the coverage area; the time window with the smallest number is determined as the target time window.

[0101] Unlike the first approach, this approach introduces regional collaborative constraints to address the coverage blind spots caused by simultaneous upgrades of adjacent roadside devices. First, it identifies other roadside devices with coverage associations with the target device (such as four adjacent RSUs at an intersection) using a Geographic Information System (GIS) or topology table. Then, it counts the number of these associated devices scheduled for upgrade in each candidate window (e.g., two adjacent devices are scheduled for upgrade between 10:00 and 10:05, while only one is scheduled between 11:30 and 11:35). Finally, it selects the window with the fewest associated devices to be upgraded, thereby avoiding simultaneous degradation of regional service capacity.

[0102] It should be noted that the two methods mentioned above can be used independently or in combination: Method 1 is preferred in scenarios where the reliability of single-device service must be strictly guaranteed; Method 2 is used in scenarios requiring regional coordination in dense deployments; for higher-level implementations, a weighted scoring model can be designed, taking into account factors such as average window busyness, the number of associated device upgrades, and even external factors such as weather or traffic flow predictions for comprehensive selection. The determination of associated devices needs to be combined with the actual deployment pattern, for example, by dynamically adjusting the association relationship through signal strength measurement or historical vehicle handover records to ensure the accuracy of coverage connection.

[0103] Furthermore, the final determination of the time window can also introduce an additional manual review mechanism. The system will generate load comparison curves for each candidate window and status dashboards for related equipment for secondary confirmation by maintenance personnel, achieving a balance between automation and manual intervention, thereby achieving dual optimization of upgrade safety and maintenance efficiency in complex urban traffic environments.

[0104] To deepen your understanding of the implementation process of steps 206 and 207 in process 200, please refer to [link to relevant documentation]. Figure 4 , Figure 4 This is a flowchart illustrating a method for constructing a training sample set and upgrading target roadside equipment using a trained traffic prediction model, as provided in an embodiment of this disclosure.

[0105] Step 401: Determine the predicted system busyness of the target roadside equipment at each predicted time based on the busyness prediction model at the preset quantile.

[0106] Step 402: Upgrade the target roadside equipment within the target time window determined based on the predicted values.

[0107] This embodiment describes the prediction phase. The busyness prediction model, combined with quantile prediction technology, outputs predicted system busyness values ​​with a preset probability at the predicted time. For example, the 90th percentile indicates that the predicted value has only a 10% probability of being greater than the actual value, and the 50th percentile indicates that the predicted value has a 50% probability of being greater than the actual value. The operations and maintenance system prioritizes time periods that remain below the safety threshold even under high quantile predictions as target time windows. This quantile prediction mechanism is particularly suitable for critical scenarios with extremely low tolerance for service interruptions, such as when deploying upgrades before peak traffic hours. Predicting the 90th percentile busyness ensures service stability even in the event of sudden traffic surges. In implementation, the quantile selection strategy needs to be dynamically adjusted: during normal periods, the 50th percentile can be used to balance efficiency and safety, while during special periods such as extreme weather, the quantile is increased to the 95th percentile to strengthen protection. The division of quantile intervals needs to match business characteristics; high-fluctuation indicators (such as concurrent request count) use finer-grained quantiles (such as every minute), while steady-state indicators (such as memory usage) can be appropriately relaxed.

[0108] Ultimately, the enhanced prediction mechanism based on quantile statistics provided in this embodiment enables the system to probabilistically avoid the worst-case scenario and control the service interruption risk of the upgrade operation within a provable range.

[0109] In practice, MECs are typically deployed at various intersections in cities, responsible for collecting data and providing intelligent transportation and smart city-related services. With the construction of smart cities and the advancement of the "AI+" initiative, the number of intelligent connected intersections in China is gradually increasing. In the integrated vehicle-road-cloud architecture, MECs can be remotely updated and upgraded via a cloud platform, generally including remote upgrades to firmware, software, high-precision maps, and parameters. Remote upgrades require certain system resources and are generally required to be performed during off-peak business hours. Furthermore, due to the specific nature of the business, service restarts or suspensions may sometimes be necessary. Determining the appropriate upgrade timing to avoid impacting the provided services during the upgrade process is a problem that urgently needs to be solved by those skilled in the art.

[0110] To address the aforementioned technical issues, this embodiment proposes a business-aware upgrade method based on the previous embodiments. Specifically, this method includes a system busyness calculation method based on entropy measurement and an upgrade window selection method based on quantile prediction. This method can dynamically sense business load and automatically select the optimal upgrade window. It enables automatic upgrades during off-peak business periods and under conditions of adequate system resources, ensuring business reliability and stability. When the MEC receives an upgrade command from the platform, it automatically predicts the optimal upgrade time window and executes the upgrade operation during that period.

[0111] Among them, business awareness refers to the detection, identification, understanding, and evaluation of business processes within the system. The business awareness system in remote upgrades is responsible for predicting future business peaks and troughs, quantifying business impact risks, dynamically selecting the optimal upgrade window, and reducing the impact of module upgrades on critical businesses. The core strategy is to collect current system and business indicators, obtain system busyness indicators based on an entropy-based system busyness calculation method proposed in this embodiment, input quantile regression models based on time period characteristics, time series characteristics, original characteristics, and weighted information entropy, predict multiple quantiles of the system busyness indicators for time h in the future, S(t+h), and finally combine this with an upgrade window selection method based on quantile prediction proposed in this embodiment, using the predicted high quantile S^(0.9) to construct risk constraints and search for upgrade windows. The following will provide a detailed explanation of the specific technical content involved:

[0112] 1. Multi-dimensional weighted information entropy

[0113] This embodiment proposes a system busyness calculation method based on entropy measurement. It normalizes multiple heterogeneous business perception dimensions (such as traffic, load, business, and key quality indicators) and quantifies system busyness using the concept of information entropy. The busier the system, the higher the values ​​of each indicator and the greater the potential fluctuations. The advantage of this method lies in unifying heterogeneous indicators with different units and dimensions into a dimensionless entropy value, representing the system's disorder and uncertainty. Peak business periods are high-entropy periods, and off-peak periods are low-entropy periods.

[0114] 1) Data Collection

[0115] MEC's ​​built-in monitoring collects business metrics every minute and stores them chronologically in a local time-series database, forming time-series data. During the initial training of the business awareness model, the data in the time-series database is processed and used as a dataset for training and testing. During business operation, it serves as input to predict future business load and resource conditions. (The collected data metric set...) (in (where i represents the value of indicator i at time t, and M represents the number of indicators) is as follows:

[0116] ① Business traffic: vehicle traffic, concurrent requests (times / second), throughput (bps), average message packet length (Byte);

[0117] ② Operating load: CPU utilization (%), memory utilization (%), GPU utilization (%), storage read / write speed, bandwidth utilization (%);

[0118] ③ Key business activity: number of autonomous vehicles, number of connected vehicles, and number of vehicles with traffic signal priority;

[0119] ④ Key Quality Indicators (KQI): Message latency P99 (ms), network packet loss rate (%), message retransmission rate (%).

[0120] 2) Data normalization

[0121] For each metric i, use historical data of T_range (7 days for business purposes) to calculate the dynamic minimum and maximum values ​​of all metrics, normalize them, and then crop the data to the range [0,1].

[0122] ;

[0123] in, :represent Time indicators Normalized index; :index The value at time t; The minimum value of this indicator; The maximum value of this indicator; : constant, to prevent When the denominator is zero, it is generally taken as zero. .

[0124] To represent the volatility of this indicator within a short window, a window is defined. Normalized standard deviation within:

[0125] ;

[0126] in, : The standard deviation of the volatility measure of index i at time t; Standard deviation calculation; : Normalized index value; : The length of the time window for volatility calculation.

[0127] 3) System Busyness Indicators

[0128] For each metric i, its contribution to the system's busy level at the current moment is defined as:

[0129] ;

[0130] in, Indicator i at time System busy level; Weighting coefficients are used to balance the contributions of "indicator level" and "indicator volatility"; weighting , In addition, considering the level and fluctuation of the indicators, the weights are initially set based on historical experience, and then fine-tuned on the validation set based on the prediction performance results.

[0131] Each indicator is then assigned a weight to reflect its relative importance to the upgrade security, and finally synthesized into a weighted sum as a system busyness indicator:

[0132] ;

[0133] in, Overall system busyness index; The weight corresponding to indicator i, and the sum of the weights of multiple indicators is 1; Number of indicators. Weights Initially set up based on historical experience, it can be dynamically adjusted during subsequent upgrade verification and testing. The specific adjustment process is as follows: measurable feedback such as success / failure, low service availability, and CPU peak limit exceedance are aggregated into a failure severity F. The contribution of each indicator within each upgrade window is used to allocate penalties, and then the indicator weights are adjusted online using multiplicative update rules.

[0134] 2. Feature Engineering

[0135] The problem of selecting the optimal upgrade window is essentially predicting a period of low system activity. First, MEC-related services exhibit strong time-cycle characteristics. For example, during morning and evening rush hours, there are more vehicles, resulting in higher loads on the perception system. Additionally, there are more autonomous and connected vehicles, leading to more system requests. Furthermore, the difference in activity levels between weekdays and holidays is quite significant. Second, system activity is temporally sequential, generally changing gradually from busy to idle, or vice versa. However, sudden events may occur at certain times. These fluctuations are learned from the original features, with key original indicators and mutation-related indicators pre-selected to form the original features. Finally, all features, along with weighted information entropy, work together to train the model.

[0136] To predict the weighted information entropy S(t+h) at time h in the future, the input features include historical data of S, some key original indicators, and time features. Compared to using all the original data as features and prediction output, using the weighted information entropy S can greatly reduce the model complexity.

[0137] 1) Business characteristics

[0138] Weighted information entropy can show the overall busyness trend, but future changes in entropy values ​​may be driven by a certain type of indicator. Therefore, using the original features can effectively preserve details, and the model can learn the magnitude of the impact of detailed factors on the future, making it more robust in high quantile predictions.

[0139] Data collected from MEC monitoring is processed, and key raw features are selected based on those that significantly contribute to system activity and have high variability, capturing the impact of fluctuations. Selected key raw features include traffic flow, concurrent request count, CPU utilization, and the number of autonomous vehicles. The business characteristics of the current time step can be represented as follows:

[0140] ;

[0141] in: : List of original features at time t; :represent Time indicators The normalized index, where i can be... , (Number of concurrent requests) (Number of autonomous vehicles), etc.

[0142] 2) Time characteristics

[0143] Time features are used to capture patterns. Traffic flow and load show obvious periodicity throughout the day. Time features are used as prior information and are automatically calculated from the collection timestamp. They mainly include hour, minute, and weekday information, and additional information such as holidays are added. Sin / cos encoding is used to enhance the periodicity representation.

[0144] Hourly features: ;

[0145] Minute-level features: Where h: the current hour (0, 1, 2, …, 23); m: the current minute (0, 1, 2, …, 60); hour_sin, hour_cos: two new features used to express the periodicity of time.

[0146] 3) Weighted information entropy time series features

[0147] This paper proposes a feature construction method that integrates the overall situation and current key details. Traditional methods either rely solely on raw monitoring metrics from various dimensions, resulting in a large input dimension, high noise, and difficulty in efficient operation on edge computing nodes; or they over-rely on a single compressed metric (such as average latency or overall utilization), causing loss of detailed information and making it difficult to accurately characterize the impact of different business load patterns on future system busyness.

[0148] This embodiment proposes a feature that integrates global situational awareness with current key details. The core of this method lies in: ① Global situational awareness: utilizing entropy value sequences. As input, it captures the overall trend and fluctuation pattern of system busyness within past time windows, avoiding the high overhead of processing all historical raw indicators dimension by dimension. This represents the system busyness score calculated at time t. ① Indicates the length of the historical window (unit: sampling period, e.g., 10 minutes); ② Current key details: at time... A set of normalized key original features is introduced to supplement the driving factors that cannot be distinguished by the global entropy value, thereby improving the model's accuracy in predicting future busyness quantiles.

[0149] Therefore, time input vector It can be represented as:

[0150] ;

[0151] in, The original feature list at time t above; : Length of the history window.

[0152] The proposed feature fusion mechanism can ensure low input dimensionality and lightweight model, making it suitable for real-time operation at edge nodes. At the same time, it takes into account the overall busy situation and key driving factors, effectively improving the accuracy of upgrade window selection.

[0153] 3. Model Training

[0154] Traditional feature engineering typically normalizes the raw indicator data and directly uses it as input to the model. This approach results in models with high dimensionality and complexity for upgraded scenarios. If multi-output regression is used to predict M indicators across N time periods, it requires training M... Predicting metrics using N models incurs high training and inference costs. The solution provided in this embodiment has the following advantages:

[0155] ① Low complexity: Business activity is quantified as information entropy S, and trained using some key original features as input. The model output is only related to S. Only one model is needed for single quantile prediction and single horizon (prediction time span) prediction, greatly reducing the difficulty and complexity of model learning. ② Quantile indicators are mapped to different stages: Since the upgrade requires a time window rather than a point in time, traditional regression is a point estimate, which can only predict the future mean of activity, not the activity distribution. Quantile regression is more suitable for interval estimation. Therefore, this invention uses the model to predict multiple quantile indicators for a future period of time for a comprehensive assessment of future system activity. Compared with ordinary regression outputting a single expected value, it better describes uncertainty. Furthermore, different upgrade stages (download, service switching, etc.) have varying tolerances for system load, and different quantile metrics can be applied to different upgrade stages; ③ Optimal principle: Predicting the quantiles of multiple horizons in the future allows for the selection of the optimal upgrade time point over a longer period based on multiple quantiles, or consecutive low-peak periods; ④ Multi-scenario application: For a single horizon, prediction can be made for the next 5 minutes, meeting the needs of small-batch or rapid upgrade scenarios; multiple horizons (e.g., 5, 15, 30 minutes) can assess the safety of longer time windows. Single quantile prediction (e.g., evaluating only p90, 90th percentile, 90th percentile) can be used for more conservative upgrades; multi-quantile prediction is used for phased upgrades (e.g., evaluating p50 during download and p90 during upgrade switching). The number of models corresponding to each method is different and can be adjusted according to MEC resources and upgrade duration.

[0156] 1) Label and training sample construction

[0157] A self-supervised learning approach is adopted, directly generating labels from the data itself according to predefined rules, and training the network with constructed supervisory information. The system collects indicator data every minute, with a time series index of [insert index here]. To predict the system state h minutes from now, the sample labels corresponding to each time point t are... Defined as: ,in The above system busyness index is calculated from historical monitoring data. This method avoids manual labeling and directly uses existing data.

[0158] Labels and inputs form sample pairs, and each training sample is represented as: Python is used to process the monitoring data from the raw time-series database, facilitating the generation of all training samples using a sliding window. Horizon is configured for multi-step training (5 / 15 / 30 minutes) based on business needs, with each Horizon training independently. The training samples are divided into training and test sets.

[0159] 2) Model Training and Inference

[0160] The model is trained in a cloud environment based on multiple horizons for quantile prediction. The prediction model can be a gradient boosting decision tree, convolutional neural network, recurrent neural network, or an improved form of quantile prediction model. Taking LightGBM as an example, after training, the model is exported, and the model and corresponding Python inference and decision engineering code are deployed to the MEC. The inference result coverage is periodically checked; if a decrease occurs, samples from the corresponding historical time period are added for retraining.

[0161] During MEC operation, data is monitored in real time and input vectors are constructed. Model inference prediction is used, with multiple models employing CPU multi-threading for parallel inference, and a single model inference time of <50ms. The model output is the quantile results for multiple future prediction steps, which are subsequently combined with entropy thresholds to determine the upgrade window.

[0162] 4. Upgrade decision

[0163] 1) Threshold selection

[0164] When selecting the optimal upgrade window, it is first necessary to determine the S_threshold (entropy threshold) for judging business downturns. This embodiment uses a data-driven dual-threshold selection method to trigger upgrades and monitor the upgrade process, as follows:

[0165] ① Calculate the intraday distribution using historical S(t) time series, and take the p20 quantile as the upper bound S_threshold_safe (safety threshold) of the historical low peak interval to trigger the upgrade; ② Take the p50 quantile as the monitoring threshold S_threshold_alert (alert threshold). During the upgrade process, calculate the real-time S(t) every minute. If the real-time S(t) exceeds S_threshold_alert, issue a risk warning as the basis for pausing the upgrade.

[0166] 2) Risk constraints

[0167] Use the upper quantile of the model output (High quantile, default) = 0.9) is used as an estimate under future uncertainty. That is, if the predicted upper quantile value is less than or equal to the upper bound of the historical low-peak interval S_threshold_safe, the current period is considered to be a low-peak window. The following are the optimal upgrade window selection strategies for various scenarios:

[0168] If MEC resources are extremely limited, and the scenarios mostly involve small-batch or rapid module upgrades, a single Horizon model plus a single p90 quantile model can be deployed to predict system busyness metrics 5 minutes later. If the maximum upper quantile within a candidate window W (continuously k minutes) is ≤ S_threshold_safe, then the window is considered low-risk. A window is determined to be low-risk. Upgrades can then be performed.

[0169] In reality, MEC upgrades are often not instantaneous, but can last from several minutes to tens of minutes. A single horizon (e.g., predicting only 5 minutes in advance) can only provide localized risk alerts and cannot guarantee the safety of the entire upgrade window. Furthermore, if the horizon setting is too large, the prediction may be significantly inaccurate. Therefore, the advantage of using multiple horizons is that they can cover the entire upgrade cycle, ensuring controllability at every moment within the window. Additionally, multiple horizons can improve decision-making flexibility, taking into account both short-term and long-term trends, and identifying future periods of sustained and stable low-peak performance.

[0170] 3) Optimal upgrade window selection strategy under multiple Horizons

[0171] The overall process is as follows: ① Construct the quantile prediction matrix for all horizons within the future T_search; ② Perform a sliding window scan on the matrix to find all windows that meet the safety conditions; ③ Select the best window according to the optimization criteria; ④ During the upgrade process, monitor the actual S(t) in real time, and pause the upgrade if it exceeds S_threshold_alert.

[0172] Below is a detailed description of the strategy, where the input is:

[0173] ①The above quantile prediction model gives the system in each horizon The predicted quantiles below: Different quantile values ​​can be selected depending on the different stages of the upgrade. Taking the upgrade switch as an example, the selected quantile value for this stage is... = 0.9 quantile; ② Expected upgrade window length ③ Thresholds: Safety threshold S_threshold_safe, Alert threshold S_threshold_alert.

[0174] Step 1: Generating the Window Candidate Set

[0175] From the current moment Begin, traverse the future All candidate start times For each candidate window Find all the predicted quantiles of Horizon that are covered in this window.

[0176] ;

[0177] in: : Upgrade window length ; : All predicted quantile values ​​within a window length W at the candidate start time s; : Predicted quantile at time h. This indicates that the higher quantile is selected, typically the 0.9 quantile.

[0178] Step 2: Window Feasibility Assessment

[0179] window The feasible conditions are: , This represents the highest predicted quantile within the window, i.e., the highest predicted quantile among all horizons within the window. All predictions were below the threshold.

[0180] Step 3: Window Priority Rules

[0181] If there are multiple feasible windows, select the optimal one: priority objective: earliest feasible; secondary objective: maximum safety margin.

[0182] Safety margin calculate: ,

[0183] Comprehensive objective function : .

[0184] in , Risk-sensitive parameters can be set based on historical experience and business risk sensitivity, and are used to adjust priority rules; This indicates the number of seconds that the feasible window start time s is delayed compared to the current time.

[0185] The following are example upgrade policy execution scenarios to help you understand them better:

[0186] Setting parameters:

[0187] ① The upgrade process takes 20 minutes. = 20; ② Predicting the horizon: = {5, 10, 15, 20, 25, 30} minutes; ③ Safety threshold: S_threshold_safe = 0.4, alert threshold: S_threshold_alert = 0.6; ④ Predicted output: 0.9 quantile of entropy (conservative assessment).

[0188] Assuming the current time The model outputs the predicted future entropy value p90 as shown in Table 1 below:

[0189] Table 1 Forecast Table

[0190]

[0191] Step 1: Generate candidate windows

[0192] W=20, the candidate window must cover at least 20 minutes, feasible candidates: A: [t+0, t+20], B: [t+5, t+25], C: [t+10, t+30];

[0193] Step 2: Assess Feasibility

[0194] Take the maximum predicted entropy value within each window: A: max(0.35,0.38,0.32,0.34) = 0.38, B: max(0.38,0.32,0.34,0.45) = 0.45, C: max(0.32,0.34,0.45,0.55) = 0.55, among which only A meets the requirement of <= S_threshold_safe = 0.4.

[0195] Step 3: Select the optimal window:

[0196] The only feasible window is A: [t, t+20].

[0197] Step 4: Upgrade Decision

[0198] The system can trigger an upgrade immediately and is expected to maintain a low entropy state for the next 20 minutes. If the actual entropy value exceeds S_threshold_alert during operation, the upgrade will be aborted, and the system will wait for the next low-entropy window.

[0199] Further reference Figure 5 As an implementation of the methods shown in the above figures, this disclosure provides an embodiment of a remote upgrade device for roadside equipment under a vehicle-road-cloud integrated architecture. This device embodiment is similar to... Figure 2 Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.

[0200] like Figure 5As shown, the roadside equipment remote upgrade device 500 under the vehicle-road-cloud integrated architecture of this embodiment may include: a historical truth value acquisition unit 501, a normalization processing and volatility determination unit 502, an index value processing unit 503, a system busyness determination unit 504, a training sample set construction unit 505, a model training unit 506, and an upgrade timing determination unit 507. The system comprises the following components: a historical truth value acquisition unit 501, configured to acquire historical truth values ​​of different dimensions of the sample roadside equipment at historical times; a normalization processing and volatility determination unit 502, configured to normalize the historical truth values ​​of each indicator under each dimension and determine the volatility of the corresponding indicator based on the calculated normalized values; an indicator value processing unit 503, configured to determine the processed value of the corresponding indicator based on the normalized value and volatility of each indicator; a system busyness determination unit 504, configured to calculate the system busyness of the sample roadside equipment at historical times based on the preset contribution weight and processed value corresponding to each indicator; and a training sample set construction unit 505, configured to construct the training sample set from the historical data. The historical true values ​​of the target are used as sample inputs, and the system busyness calculated from the historical true values ​​of each indicator at the prediction time after the historical time is used as sample output, thus constructing a training sample set containing multiple sample pairs. Among them, key indicators refer to some or all of the indicators used to describe information interaction with vehicles that can interact with information. The model training unit 506 is configured to train the preset model using the training sample set to obtain a busyness prediction model for predicting system busyness. The upgrade timing determination unit 507 is configured to determine the predicted value of the system busyness of the target roadside equipment at each prediction time through the busyness prediction model, and perform upgrade operations on the target roadside equipment in the target time window determined based on the predicted value.

[0201] In this embodiment, the specific processing and technical effects of the following components in the roadside equipment remote upgrade device 500 under the vehicle-road-cloud integrated architecture—including the historical truth value acquisition unit 501, the normalization processing and volatility determination unit 502, the index value processing unit 503, the system busyness determination unit 504, the training sample set construction unit 505, the model training unit 506, and the upgrade timing determination unit 507—can be found in reference to [the relevant documentation / reference]. Figure 2 The relevant descriptions of steps 201-207 in the corresponding embodiments will not be repeated here.

[0202] In some other optional implementations of this embodiment, the normalization processing and volatility determination unit 502 is further configured to:

[0203] For each indicator under each dimension, the historical true values ​​within a preset time period before the historical moment are obtained, and the maximum and minimum true values ​​are determined based on the historical true values ​​within the preset time period before the historical moment. Based on the value range determined by the maximum and minimum true values, the historical true values ​​at the historical moment are normalized to obtain the normalized values ​​of the corresponding indicators.

[0204] For each indicator under each dimension, the standard deviation between the normalized values ​​of the corresponding indicator within a preset time window is used to determine the degree of fluctuation of the corresponding indicator; the preset time window is determined based on the actual business duration of the sample roadside equipment.

[0205] In some other optional implementations of this embodiment, the index value processing unit 503 is further configured to:

[0206] For each indicator in each dimension, a first weight corresponding to the normalized value of the corresponding indicator at a historical time and a second weight corresponding to the degree of fluctuation of the corresponding indicator at a historical time are determined.

[0207] For each indicator under each dimension, the normalized value obtained by weighting the first weight of the corresponding indicator with the fluctuation level obtained by weighting the second weight will be used to determine the processed value of the corresponding indicator.

[0208] In some other optional implementations of this embodiment, the upgrade timing determination unit 507 includes a prediction value determination subunit configured to determine the predicted system busyness of the target roadside equipment at each prediction time using a busyness prediction model. The prediction value determination subunit is further configured to:

[0209] Obtain the current values ​​of different dimensions of the target roadside equipment at the current moment;

[0210] The system busyness of the target roadside equipment at the current moment is calculated based on the current values ​​of each indicator;

[0211] The system busyness of the target roadside equipment at the current time and the current values ​​of key indicators are input into the busyness prediction model to obtain the predicted values ​​of the system busyness of the target roadside equipment at each prediction time.

[0212] In some other optional implementations of this embodiment, the upgrade timing determination unit 507 includes an upgrade operation execution subunit for performing upgrade operations on the target roadside equipment within a target time window determined based on predicted values. The upgrade operation execution subunit includes:

[0213] The size comparison module is configured to compare the predicted values ​​of the system busyness of the target roadside equipment at different prediction times with the busyness thresholds pre-set for the target roadside equipment.

[0214] The target time window determination module is configured to determine the target time window that meets the upgrade duration requirement among all predicted times with predicted values ​​less than the busy threshold; wherein, the upgrade duration requirement is determined based on a comprehensive consideration of the data size used in the upgrade operation, transmission time, and device performance.

[0215] The upgrade operation control execution module is configured to control the target roadside equipment to perform upgrade operations within the target time window.

[0216] In some other optional implementations of this embodiment, the target time window determination module is further configured to:

[0217] In response to the existence of multiple time windows that all meet the upgrade duration requirements, the average value of the predicted system busyness for each time window is determined.

[0218] The time window with the smallest average value is determined as the target time window.

[0219] In some other optional implementations of this embodiment, the target time window determination module is further configured to:

[0220] In response to the existence of multiple time windows that all meet the upgrade duration requirements, the number of associated roadside devices scheduled to perform upgrade operations in each time window is determined; where associated roadside devices refer to other roadside devices that are associated with the target roadside device in the coverage area.

[0221] The time window with the smallest number of elements is determined as the target time window.

[0222] In some other optional implementations of this embodiment, the upgrade timing determination unit 507 is further configured to:

[0223] The predicted system busyness of the target roadside equipment at each predicted time point is determined by the busyness prediction model.

[0224] Upgrade the target roadside equipment within the target time window determined based on the predicted values.

[0225] In some other optional implementations of this embodiment, the different dimension indicators include multiple indicators under multiple dimensions. The different types of dimensions include: traffic characteristic dimension, load characteristic dimension, service characteristic dimension, and network quality characteristic dimension. The multiple indicators under the traffic characteristic dimension include: vehicle traffic, number of concurrent requests, data throughput, and average message packet length. The multiple indicators under the load characteristic dimension include: CPU utilization, memory utilization, GPU utilization, read / write speed, and bandwidth utilization. The multiple indicators under the service characteristic dimension include: the number of autonomous vehicles capable of information interaction, the number of connected vehicles, and the number of vehicles with traffic signal priority. The multiple indicators under the network quality characteristic dimension include: message latency, packet loss rate, and retransmission rate.

[0226] In some other optional implementations of this embodiment, the key metrics include at least one of the following metrics:

[0227] Traffic volume, number of concurrent requests, CPU utilization, and number of autonomous vehicles.

[0228] This embodiment is a device embodiment corresponding to the above method embodiment. The roadside equipment remote upgrade device under the vehicle-road-cloud integrated architecture provided in this embodiment first obtains the historical true values ​​of different dimensions of the sample roadside equipment at historical times, so as to include a sufficient number of parameters describing the system's busyness. Then, by normalizing the historical true values ​​and calculating the degree of fluctuation, the processed values ​​of each indicator can ignore the different units used by each indicator and avoid the influence of fluctuation on the indicator values. Next, the processed values ​​of each indicator are weighted according to the contribution degree of different indicators to the system busyness, thereby improving the accuracy of the calculated system busyness in describing the actual situation. The next step is to add the historical true values ​​of key indicators to the sample input, so that the model can better learn the actual contribution of these key indicators to the predicted value during the training phase. This improves the prediction accuracy of the trained busyness prediction model, and then uses the busyness prediction model to determine the appropriate target time window for upgrading the target roadside equipment to perform the upgrade operation, ultimately reducing the risk of service interruption caused by the roadside equipment performing the upgrade operation.

[0229] According to embodiments of this disclosure, this disclosure also provides an electronic device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to implement the remote upgrade method for roadside equipment under the vehicle-road-cloud integrated architecture described in any of the above embodiments.

[0230] According to embodiments of this disclosure, this disclosure also provides a readable storage medium storing computer instructions that enable a computer to implement the remote upgrade method for roadside equipment under the vehicle-road-cloud integrated architecture described in any of the above embodiments.

[0231] According to embodiments of this disclosure, this disclosure also provides a computer program product that, when executed by a processor, can implement the remote upgrade method for roadside equipment under the vehicle-road-cloud integrated architecture described in any of the above embodiments.

[0232] Figure 6 A schematic block diagram of an example electronic device 600 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0233] like Figure 6 As shown, device 600 includes a computing unit 601, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 602 or a computer program loaded into random access memory (RAM) 603 from storage unit 608. RAM 603 may also store various programs and data required for the operation of device 600. The computing unit 601, ROM 602, and RAM 603 are interconnected via bus 604. Input / output (I / O) interface 605 is also connected to bus 604.

[0234] Multiple components in device 600 are connected to I / O interface 605, including: input unit 606, such as keyboard, mouse, etc.; output unit 607, such as various types of monitors, speakers, etc.; storage unit 608, such as disk, optical disk, etc.; and communication unit 609, such as network card, modem, wireless transceiver, etc. Communication unit 609 allows device 600 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0235] The computing unit 601 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 601 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 601 performs the various methods and processes described above, such as the roadside equipment remote upgrade method under a vehicle-road-cloud integrated architecture. For example, in some embodiments, the roadside equipment remote upgrade method under a vehicle-road-cloud integrated architecture can be implemented as a computer software program, which is tangibly contained in a machine-readable medium, such as storage unit 608. In some embodiments, part or all of the computer program can be loaded and / or installed on device 600 via ROM 602 and / or communication unit 609. When the computer program is loaded into RAM 603 and executed by the computing unit 601, one or more steps of the roadside equipment remote upgrade method under a vehicle-road-cloud integrated architecture described above can be performed. Alternatively, in other embodiments, the computing unit 601 may be configured by any other suitable means (e.g., by means of firmware) to perform a remote upgrade method for roadside equipment under a vehicle-road-cloud integrated architecture.

[0236] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0237] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0238] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0239] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0240] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0241] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and Virtual Private Server (VPS) services, such as high management difficulty and weak business scalability.

[0242] According to the technical solution of this disclosure, firstly, by obtaining the historical true values ​​of different dimensions of roadside equipment at historical times, a sufficient number of parameters describing system busyness can be included in the consideration. Then, by normalizing the historical true values ​​and calculating the degree of fluctuation, the processed values ​​of each indicator can ignore the different units used by each indicator and avoid the influence of fluctuation on the indicator values. Next, by using the contribution weights of different indicators to the system busyness, the processed values ​​of each indicator are weighted, thereby improving the accuracy of the calculated system busyness in describing the actual situation. The next step is to add the historical true values ​​of key indicators to the sample input, so that the model can better learn the actual contribution of these key indicators to the predicted value during the training phase. This improves the prediction accuracy of the trained busyness prediction model, enabling the model to determine a suitable target time window for upgrading the target roadside equipment and perform the upgrade operation, ultimately reducing the risk of service interruption caused by the roadside equipment performing upgrade operations.

[0243] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

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

Claims

1. A method for remotely upgrading roadside equipment under a vehicle-road-cloud integrated architecture, characterized in that, include: Obtain the historical true values ​​of different dimensions of the sample roadside equipment at historical times; The historical true values ​​of each indicator under each dimension are normalized, and the degree of fluctuation of the corresponding indicator is determined based on the calculated normalized values. The processed value of each indicator is determined based on the normalized value and volatility of each indicator. The system busyness of the sample roadside equipment at the historical time is calculated based on the preset contribution weight and processed value corresponding to each of the indicators. The system busyness at the historical time and the historical true value of key indicators are used as sample inputs, and the system busyness calculated from the historical true value of each indicator at the predicted time after the historical time is used as sample output, to construct a training sample set containing multiple sample pairs; wherein, the key indicators refer to some or all of the indicators used to describe information interaction with vehicles that can interact with information among all types of indicators. The preset model is trained using the training sample set to obtain a busyness prediction model for predicting system busyness. The system busyness prediction model is used to determine the predicted values ​​of the target roadside equipment at each prediction time, and the target roadside equipment is upgraded within the target time window determined based on the predicted values.

2. The method according to claim 1, characterized in that, The process of normalizing the historical true values ​​of each indicator under each dimension and determining the fluctuation level of the corresponding indicator based on the calculated normalized values ​​includes: For each indicator under each dimension, the historical true values ​​within a preset time period before the historical moment are obtained, and the maximum and minimum true values ​​are determined based on the historical true values ​​within the preset time period before the historical moment. The historical true values ​​at the historical moment are normalized based on the value range determined by the maximum and minimum true values ​​to obtain the normalized value of the corresponding indicator. For each indicator under each dimension, the standard deviation between the normalized values ​​of the corresponding indicator within a preset time window is used to determine the fluctuation level of the corresponding indicator; wherein, the preset time window is determined based on the actual business duration of the sample roadside equipment.

3. The method according to claim 1, characterized in that, The process of determining the processed value of the corresponding indicator based on the normalized value and volatility of each indicator includes: For each indicator in each dimension, a first weight corresponding to the normalized value of the corresponding indicator at the historical time and a second weight corresponding to the degree of fluctuation of the corresponding indicator at the historical time are determined. For each indicator under each dimension, the normalized value obtained by weighting the first weight of the corresponding indicator with the fluctuation level obtained by weighting the second weight will be used to determine the processed value of the corresponding indicator.

4. The method according to claim 1, characterized in that, The step of determining the predicted system busyness of the target roadside equipment at each prediction time using the busyness prediction model includes: Obtain the current values ​​of different dimensions of the target roadside equipment at the current moment; The system busyness of the target roadside equipment at the current time is calculated based on the current values ​​of each indicator; The system busyness of the target roadside equipment at the current time and the current value of the key indicator are input into the busyness prediction model to obtain the predicted value of the system busyness of the target roadside equipment at each prediction time.

5. The method according to claim 1, characterized in that, The upgrade operation of the target roadside equipment within the target time window determined based on the predicted value includes: The predicted values ​​of the system busyness of the target roadside equipment at different predicted times are compared with the busyness thresholds pre-set for the target roadside equipment. Among all predicted times with predicted values ​​less than the busyness threshold, a target time window is determined to meet the upgrade duration requirement; wherein the upgrade duration requirement is determined based on a comprehensive consideration of the data size, transmission time, and device performance used in the upgrade operation. Control the target roadside equipment to perform upgrade operations within the target time window.

6. The method according to claim 5, characterized in that, Determining the target time window that meets the upgrade duration requirement among all predicted times with predicted values ​​less than the busyness threshold includes: In response to the existence of multiple time windows that all meet the upgrade duration requirements, the average value of the predicted system busyness for each time window is determined. The time window with the smallest average value is determined as the target time window.

7. The method according to claim 5, characterized in that, Determining the target time window that meets the upgrade duration requirement among all predicted times with predicted values ​​less than the busyness threshold includes: In response to the existence of multiple time windows that all meet the upgrade duration requirement, the number of associated roadside devices scheduled to perform upgrade operations in each time window is determined; wherein, the associated roadside devices refer to other roadside devices that are associated with the target roadside device in the coverage area; The time window with the smallest number is determined as the target time window.

8. The method according to claim 1, characterized in that, The step of determining the predicted system busyness of the target roadside equipment at each predicted time using the busyness prediction model, and then performing upgrade operations on the target roadside equipment within the target time window determined based on the predicted values, includes: The system busyness prediction model determines the predicted value of the target roadside equipment at a preset quantile at each predicted time, and upgrades the target roadside equipment within the target time window determined based on the predicted value.

9. The method according to any one of claims 1-8, wherein, The different dimensional indicators include multiple indicators under multiple dimensions. These different types of dimensions include: traffic characteristic dimension, load characteristic dimension, service characteristic dimension, and network quality characteristic dimension. The multiple indicators under the traffic characteristic dimension include: vehicle traffic, concurrent request count, data throughput, and average message packet length. The multiple indicators under the load characteristic dimension include: CPU utilization, memory utilization, GPU utilization, read / write speed, and bandwidth utilization. The multiple indicators under the service characteristic dimension include: the number of autonomous vehicles capable of information interaction, the number of connected vehicles, and the number of vehicles with traffic signal priority. The multiple indicators under the network quality characteristic dimension include: message latency, packet loss rate, and retransmission rate.

10. The method according to claim 9, wherein, The key indicators include at least one of the following: The traffic flow, the number of concurrent requests, the CPU utilization rate, and the number of autonomous vehicles.

11. A remote upgrade device for roadside equipment under a vehicle-road-cloud integrated architecture, characterized in that, include: The historical truth value acquisition unit is configured to acquire the historical truth values ​​of different dimensions of the sample roadside equipment at historical moments; The normalization and volatility determination unit is configured to normalize the historical true value of each indicator under each dimension, and determine the volatility of the corresponding indicator based on the calculated normalized value. The indicator value processing unit is configured to determine the processed value of the corresponding indicator based on the normalized value and the degree of fluctuation of each of the indicators. The system busyness determination unit is configured to calculate the system busyness of the sample roadside equipment at the historical time based on the preset contribution weight and processed value corresponding to each of the indicators. The training sample set construction unit is configured to take the system busyness at the historical time and the historical true value of the key indicators as sample input, and take the system busyness calculated from the historical true value of each of the indicators at the predicted time after the historical time as sample output, and construct a training sample set containing multiple sample pairs; wherein, the key indicators refer to some or all of the indicators used to describe information interaction with vehicles that can interact with information among all types of indicators. The model training unit is configured to train a preset model using the training sample set to obtain a busyness prediction model for predicting system busyness. The upgrade timing determination unit is configured to determine the predicted value of the system busyness of the target roadside equipment at each predicted time through the busyness prediction model, and to perform upgrade operations on the target roadside equipment within the target time window determined based on the predicted value.

12. An electronic device, comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the remote upgrade method for roadside equipment under the vehicle-road-cloud integrated architecture as described in any one of claims 1-10.

13. A non-transitory computer-readable storage medium storing computer instructions, the computer instructions being configured to cause the computer to execute the remote upgrade method for roadside equipment under the vehicle-road-cloud integrated architecture according to any one of claims 1-10.

14. A computer program product comprising a computer program that, when executed by a processor, implements the steps of the remote upgrade method for roadside equipment under the vehicle-road-cloud integrated architecture according to any one of claims 1-10.

Images