Transparent software updating method and device based on program entity activity modulation

Abstract

The invention relates to a transparent software updating method and device based on program entity activity modulation, and the method comprises the steps: obtaining state data and service dependence topology of a software component in real time, the state data comprising CPU usage rate, memory usage rate, network throughput and response time; based on the trained prediction model and the current state data, predicting the state data of the software component at the next moment to obtain predicted state data; calculating the activity degree of each software component based on the prediction state data, and determining the state classification of each software component; outputting an update decision through request analysis, window scoring and sequence planning based on the service dependency topology, the prediction state data and the state classification of each software component; the updating decision comprises updating time, an updating sequence and a resource demand; and executing transparent updating based on the updating decision. According to the invention, through prediction of the service dependence topology and the real-time state data, the stability and reliability of transparent updating and the resource utilization rate are improved.

Description

Technical Field

[0001] This invention belongs to the field of vehicle software technology, specifically relating to a transparent software update method and apparatus based on program entity activity modulation. Background Technology

[0002] Current vehicle software update technology mainly adopts the traditional explicit update method, and the following technical solutions exist: 1. Forced Interruption Update: This method requires the vehicle to be in a specific state before performing a software update, completing the ECU software upgrade through a predefined update process. While this technology is highly reliable, it necessitates an explicit interruption of current services, severely impacting the user experience.

[0003] 2. Partial Online Update Solution: For example, the partial online update technology used in the VIDAR system allows updating some ECU software while the vehicle is running. However, this technology suffers from issues such as system performance fluctuations and functional limitations during the update process.

[0004] 3. Silent update technology: This method downloads the update package in the background and triggers the installation at a specific time. However, this method still requires the target system to enter a special update mode, affecting the continuity of normal services.

[0005] The existing technology has the following main technical defects: 1. Poor service continuity: Traditional updates require explicit service interruptions, with each update affecting normal service for an average of 30-60 minutes, reducing service availability.

[0006] 2. Impaired user experience: Related functions are limited or unavailable during the update process, which seriously affects application scenarios with high requirements for continuous service.

[0007] 3. Inadequate resource allocation: The update process consumes a large amount of system resources, causing the performance of other services to degrade and resulting in response delays.

[0008] 4. Insufficient flexibility: It cannot dynamically adjust the update strategy according to the real-time system load, making it difficult to adapt to complex and ever-changing operating environments.

[0009] 5. Business continuity risk: Sudden service interruptions may trigger business risks, especially in critical business scenarios. Summary of the Invention

[0010] To address the problems raised in the background art, one aspect of the present invention provides a transparent software update method based on program entity activity modulation, comprising: real-time acquisition of state data and service dependency topology of software components, wherein the state data includes CPU utilization, memory utilization, network throughput, and response time; training a prediction model; predicting the state data of the software components at the next moment based on the trained prediction model and the current state data, thereby obtaining predicted state data; calculating the activity of each software component based on the predicted state data, and determining the state classification of each software component; outputting an update decision based on the service dependency topology, the predicted state data, and the state classification of each software component, through request analysis, window scoring, and sequence planning; wherein the update decision includes update time, update sequence, and resource requirements; and performing a transparent update based on the update decision.

[0011] In some embodiments of the present invention, calculating the activity of each software component based on the predicted state data includes: calculating activity scores for CPU utilization, memory utilization, network throughput, and response time respectively based on the predicted state data and through preset thresholds; and calculating the activity of each software component by weighting based on preset weights and the activity scores.

[0012] Furthermore, determining the state classification of each software component includes: if the activity level of the software component is greater than or equal to a first threshold, the software component is judged to be in a high-activity state; if the activity level of the software component is greater than or equal to a second threshold and less than the first threshold, the software component is judged to be in a medium-activity state; if the activity level of the software component is less than the second threshold, the software component is judged to be in a low-activity state.

[0013] In some embodiments of the present invention, the step of outputting update decisions based on service dependency topology, predicted state data, and state classification of each software component, through request analysis, window scoring, and sequence planning, includes: determining the resource requirements for component updates based on request analysis; generating candidate time windows within a preset time period; determining update times from the candidate time windows based on predicted state data; and determining update sequences based on service dependency topology and state classification of each software component.

[0014] Furthermore, determining the update time from the candidate time window based on the predicted state data includes: calculating the update score of the candidate time window based on CPU utilization, memory utilization, network throughput, and window duration; and taking the start time corresponding to the candidate time window with the highest update score as the update time.

[0015] In the above embodiments, the transparent update based on the update decision includes: performing resource reservation confirmation, traffic scheduling, and service level adjustment based on the resource requirements of the update decision; and performing the transparent update after the resource reservation confirmation, traffic scheduling, and service level adjustment are completed.

[0016] A second aspect of the present invention provides a transparent software update apparatus based on program entity activity modulation, comprising: an acquisition module for acquiring in real time state data and service dependency topology of software components, the state data including CPU utilization, memory utilization, network throughput, and response time; a prediction module for training a prediction model to predict the state data of the software components at the next moment based on the trained prediction model and the current state data, thereby obtaining predicted state data; a determination module for calculating the activity of each software component based on the predicted state data and determining the state classification of each software component; an output module for outputting an update decision based on the service dependency topology, the predicted state data, and the state classification of each software component, through request analysis, window scoring, and sequence planning; the update decision including update time, update sequence, and resource requirements; and an execution module for executing a transparent update based on the update decision.

[0017] A third aspect of the present invention provides an electronic device comprising: one or more processors; and a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the transparent software update method based on program entity activity modulation provided in the first aspect of the present invention.

[0018] In a fourth aspect, the present invention provides a computer-readable medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the transparent software update method based on program entity activity modulation provided in the first aspect of the present invention.

[0019] The beneficial effects of this invention are: This invention achieves significantly improved service continuity through transparent updates; greatly improved system stability and optimized resource utilization efficiency through effective resource planning and scheduling; maintained availability of critical services above 99.5% during the update process; reduced system performance fluctuations by 65%, ensuring business continuity; supported zero-interruption updates for critical services; reduced resource conflicts during the update process by 55% through intelligent resource coordination; improved storage utilization efficiency by 35% and optimized computing resource utilization by 30%; and achieved more balanced communication bandwidth usage, avoiding network congestion. Attached Figure Description

[0020] Figure 1This is a schematic diagram of the basic process of a transparent software update method based on program entity activity modulation in some embodiments of the present invention; Figure 2 This is a schematic diagram illustrating the specific process of activity calculation in some embodiments of the present invention; Figure 3 This is a schematic diagram of the structure of a transparent software update device based on program entity activity modulation in some embodiments of the present invention; Figure 4 This is a schematic diagram of the structure of an electronic device in some embodiments of the present invention. Detailed Implementation

[0021] The principles and features of the present invention are described below with reference to the accompanying drawings. The examples given are only for explaining the present invention and are not intended to limit the scope of the present invention.

[0022] Example 1 refer to Figure 1 and Figure 2 In a first aspect of the present invention, a transparent software update method based on program entity activity modulation is provided, comprising: S100. Real-time acquisition of state data and service dependency topology of software components, wherein the state data includes CPU utilization, memory utilization, network throughput, and response time; S200. Predicting the state data of the software components at the next moment based on a trained prediction model to obtain predicted state data; S300. Calculating the activity of each software component based on the predicted state data and determining the state classification of each software component; S400. Outputting an update decision based on the service dependency topology, the predicted state data, and the state classification of each software component through request analysis, window scoring, and sequence planning; wherein the update decision includes update time, update sequence, and resource requirements; S500. Performing a transparent update based on the update decision.

[0023] In step S100 of some embodiments of the present invention, state data and service dependency topology of software components are obtained, the state data including CPU utilization, memory utilization, network throughput and response time; Specifically, the system monitors the real-time utilization of computing resources, storage usage, and communication bandwidth utilization of each software component; it collects key indicators such as component response latency and processing throughput through performance probes; it constructs inter-service call topologies and analyzes business dependencies; and to achieve comprehensive monitoring of the software system, a lightweight monitoring agent is first injected into each software component, with a sampling interval of 100 milliseconds. These agents will be responsible for collecting key performance indicators, including CPU utilization, memory usage, network I / O, and response time.

[0024] The collected data is sent to the analysis module for processing in real time through the established data transmission channel. When constructing the service dependency topology, the system obtains a list of currently running services from the service registry. For each service in the list, the system extracts the call relationships between services by parsing its call chain logs and constructs an adjacency matrix based on this information. In this matrix, if service A calls service B, the value of dependency_matrix[A][B] at the corresponding position will be recorded as the call frequency between the two. Based on the call frequency, the dependency relationship will be further marked as a strong dependency (more than 10 times / minute) or a weak dependency (no more than 10 times / minute).

[0025] In step S200 of some embodiments of the present invention, based on the trained prediction model and the current state data, the state data of the software component at the next moment is predicted to obtain the predicted state data. Specifically, during the business baseline establishment phase, the system collects historical operational data as a training set and aggregates it at a 5-minute time granularity. This data is used to train an LSTM prediction model, whose input and output dimensions are data points from the past 24 hours (i.e., 24×12). The model training involves 100 iterations. In each iteration, the mean squared error between the predicted and actual values ​​is calculated, and the network weights are updated using the backpropagation algorithm to continuously improve prediction accuracy.

[0026] refer to Figure 2 In step S300 of some embodiments of the present invention, calculating the activity of each software component based on the predicted state data and determining the state classification of each software component includes: S301. Based on the predicted state data, calculate the activity scores for CPU utilization, memory utilization, network throughput, and response time respectively using preset thresholds; Specifically, the real-time activity of the component is calculated based on multi-dimensional indicators, and the calculation formula is as follows: A=λ1·(1-CPU%)+λ2·(1-Mem%)+λ3·CommQuality+λ4·ServiceCriticality, Where A represents activity level; CPU% represents CPU utilization, Mem% represents memory utilization, CommQuality represents communication quality, ServiceCriticism represents service importance, and λ1-λ4 represent weights.

[0027] S302. Calculate the activity of each software component based on the preset weights and the activity score.

[0028] Furthermore, in step S303, determining the state classification of each software component includes: If the activity level of a software component is greater than or equal to the first threshold, the software component is judged to be in a highly active state. If the activity level of a software component is greater than or equal to the second threshold and less than the first threshold, the software component is judged to be in a medium-active state. If the activity level of a software component is less than the second threshold, the software component is judged to be in a low-activity state.

[0029] Specifically, after receiving the raw metric data (raw_metrics), a sliding window average with a window size of 10 is first applied to obtain the smoothed metric (smoothed_metrics). Then, outlier detection is performed: if a metric value is greater than the upper quartile (Q3) plus 1.5 times the interquartile range (IQR), or less than the lower quartile (Q1) minus 1.5 times the IQR, linear interpolation is used to fill the gap. Finally, the metric is normalized, mapping the original range [0, 100%] to the interval [0, 1].

[0030] During the activity calculation phase, the following operations are performed sequentially for each component: cpu_score=1-min(cpu_usage / 80%,1.0) memory_score=1-min(memory_usage / 90%,1.0) network_score=1-min(network_latency / 100ms,1.0) and the service criticality weight is obtained: service_weight=get_service_criticality(component).

[0031] The overall activity score of the component is calculated using the following weighted formula: After calculating activity_score = 0.3 × cpu_score + 0.3 × memory_score + 0.2 × network_score + 0.2 × service_weight, update the activity time series of this component.

[0032] The system categorizes components based on their activity score: if the activity score is ≥ 0.8, the state is marked as "HIGH_ACTIVITY"; if the activity score is ≥ 0.5, the state is marked as "MEDIUM_ACTIVITY"; otherwise, it is marked as "LOW_ACTIVITY". When a component's state changes, the system triggers a state change event and records the corresponding timestamp. Finally, the system outputs a real-time component activity data stream, state classification results, anomaly alerts, and an activity trend report.

[0033] In step S400 of some embodiments of the present invention, the step of outputting an update decision based on service dependency topology, predicted state data, and state classification of each software component, through request analysis, window scoring, and sequence planning, includes: S401. Based on request analysis, determine the resource requirements for component updates; generate candidate time windows within a preset time period; S402. Determine the update time from the candidate time window based on the predicted state data; Furthermore, determining the update time from the candidate time window based on the predicted state data includes: calculating the update score of the candidate time window based on CPU utilization, memory utilization, network throughput, and window duration; and taking the start time corresponding to the candidate time window with the highest update score as the update time.

[0034] Specifically, the metadata of the update package is parsed, including: determining the update type (e.g., security update, feature update, etc.), identifying affected components, and estimating the update duration based on package size and complexity. Then, priorities and time limits are set according to the update type: security updates have a "high" priority and must be executed within 1 hour; feature updates have a "medium" priority with a maximum wait time of 24 hours; other updates have a "low" priority and are allowed to be completed within 7 days. Next, window scoring is performed. The system generates a list of candidate windows for the next 6 hours from the current time, at 15-minute intervals. For each candidate window, multiple factors are comprehensively evaluated: the predicted system activity at the start time of the window, the expected business impact, the predicted system load, and network conditions. The comprehensive score is calculated using the formula: 0.4 (1 - Business Impact) + 0.3 (1 - System load) + 0.2 Update priority +0.1 Network conditions. Ultimately, the system will select the window with the highest overall score as the optimal update window.

[0035] S403. Determine the update sequence based on the service dependency topology and the state classification of each software component.

[0036] Specifically, based on the service dependency topology graph, components requiring updates are topologically sorted to ensure dependencies are handled correctly. Simultaneously, a liveness constraint is applied: if a component's current liveness is below 0.3 in the sorting result, its update priority is increased to ensure completion as quickly as possible when the system is relatively idle. Furthermore, to control risk, the system sets parallel update limits, such as a maximum of three parallel updates. The output update decision includes: the optimal update window time, the component update execution sequence, the resource plan required for the update, and a risk assessment report for this update.

[0037] In step S500 of the above embodiment, performing a transparent update based on the update decision includes: S501. Based on the resource requirements of the updated decision, perform resource reservation confirmation, traffic scheduling, and service level adjustment; Specifically, the inputs for this step include the update execution plan, current resource status, and system activity monitoring data. The processing logic first involves resource reservation: the system calculates the resource requirements for the update based on the activity monitoring data, and requests reservations after increasing buffers for CPU, memory, and network bandwidth by 20%, 20%, and 10% respectively. If resources are sufficient, the corresponding quotas are locked and isolated; otherwise, an expansion process is triggered. Next, traffic scheduling is performed: for each component to be updated, the system gradually reduces its traffic load, setting traffic limits at 0%, 25%, 50%, and 75% respectively, waiting a 2-minute stabilization period after each setting and checking the system status. Simultaneously, long-connection clients are notified to migrate to a backup instance, and a 30-second connection migration timeout is set. Finally, service degradation occurs: the system prioritizes functions, ensuring 100% availability for core functions, limiting important functions to 50% capacity, pausing enhancement functions, and delaying background tasks. The entire process is monitored for degradation status; if it exceeds 30 minutes, an alarm is triggered and a rollback is considered. Outputs include: resource reservation confirmation, traffic scheduling strategy, service degradation status, and coordination completion signal.

[0038] S502. After resource reservation confirmation, traffic scheduling, and service level adjustments are completed, a transparent update will be performed.

[0039] Specifically, this step takes as input the update binary package, coordination completion status, and component update sequence. The processing logic begins with version switch preparation: update packages are pre-downloaded and verified to a temporary directory for each component to be updated. After environment initialization, a Unix Domain Socket communication channel is established between the old and new versions for state synchronization. Then comes the hot update operation: the system starts the new version process, running it in parallel with the old process. New requests are routed to the new process, while existing requests are still handled by the old process. The system monitors the Quality of Service (QoS) of both processes. If the new process meets the QoS, existing requests are gradually migrated and the old process is shut down; otherwise, a rollback is performed. Finally, state migration occurs, including exporting, importing, and verifying the consistency of session state, as well as the smooth transfer of database connection pools, cached data, and file handles. Outputs include: update execution status, version switch results, state migration report, and exception event logs.

[0040] Specifically, this includes: After the status restoration and verification input update completion status, system monitoring data, and business verification test cases are updated, the system first performs functional restoration: restoring the non-core functions of degraded components one by one in reverse dependency order, observing each component for 5 minutes after restoration, and confirming system stability before moving on to the next. Next, performance verification is performed: verifying business logic using automated test suites (functional, performance, load) and monitoring key business metrics, requiring an error rate below 0.1%, response time not exceeding 1.2 times the baseline value, and throughput exceeding 80% of the baseline value. Finally, resource release is performed, removing resource isolation, returning quotas, cleaning up temporary files, and archiving the performance metrics, configuration change records, and summary report of this update. Outputs include: functional restoration confirmation, performance verification report, resource release status, and update summary document.

[0041] The effectiveness evaluation and optimization step takes into account update process data, performance monitoring metrics, and user feedback. The processing logic first analyzes the metrics, calculating key indicators such as total time consumption, business impact, resource efficiency, and success rate, and compares them with historical data to assess changes in performance, stability, and user experience. Then, based on the analysis results, parameter tuning is performed, including optimizing the weight coefficients of the activity model using methods such as gradient descent, and adjusting the scoring parameters of the window selection algorithm and the business impact model based on historical success patterns. Outputs include: an effectiveness evaluation report, parameter optimization suggestions, improvement action plans, and updated knowledge base content.

[0042] After accumulating complete update records, performance monitoring data, and issue handling logs, the system first performs pattern learning: It constructs a training dataset with features such as time, load, activity, and update type, and labels including success rate, impact, and time consumption. This dataset is used to train a decision tree model with a maximum depth of 10, generating update templates that include recommendation parameters and avoidance strategies. Finally, the system evolves. It retrains the prediction model monthly to maintain accuracy and continuously monitors component changes, dynamically updating dependency topologies and monitoring metrics to achieve adaptive architecture adjustments. Outputs include: an update pattern knowledge base, an optimized prediction model, system evolution suggestions, and best practice documents.

[0043] Example 2 refer to Figure 3In a second aspect, the present invention provides a transparent software update apparatus 1 based on program entity activity modulation, comprising: an acquisition module 11, configured to acquire in real time state data and service dependency topology of software components, the state data including CPU utilization, memory utilization, network throughput, and response time; a prediction module 12, configured to predict the state data of the software components at the next moment based on a trained prediction model, thereby obtaining predicted state data; a determination module 13, configured to calculate the activity of each software component based on the predicted state data and determine the state classification of each software component; an output module 14, configured to output an update decision based on the service dependency topology, the predicted state data, and the state classification of each software component, through request analysis, window scoring, and sequence planning; the update decision including update time, update sequence, and resource requirements; and an execution module 15, configured to execute a transparent update based on the update decision.

[0044] Furthermore, the determining module 13 includes: a first calculation unit, used to calculate the activity scores of CPU utilization, memory utilization, network throughput and response time respectively based on the predicted state data and through preset thresholds; and a second calculation unit, used to calculate the activity of each software component by weighting based on preset weights and the activity scores.

[0045] Example 3 refer to Figure 4 A third aspect of the present invention provides an electronic device comprising: one or more processors; and a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the transparent software update method based on program entity activity modulation of the first aspect of the present invention.

[0046] Electronic device 500 may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 501, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 502 or a program loaded from storage device 508 into random access memory (RAM) 503. The RAM 503 also stores various programs and data required for the operation of electronic device 500. The processing unit 501, ROM 502, and RAM 503 are interconnected via bus 504. An input / output (I / O) interface 505 is also connected to bus 504.

[0047] Typically, the following devices can be connected to I / O interface 505: input devices 506 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 507 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 508 including, for example, hard disks; and communication devices 509. Communication device 509 allows electronic device 500 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 4 An electronic device 500 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively. Figure 4 Each box shown can represent a device or multiple devices as needed.

[0048] Specifically, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 509, or installed from a storage device 508, or installed from a ROM 502. When the computer program is executed by a processing device 501, it performs the functions defined in the methods of embodiments of this disclosure. It should be noted that the computer-readable medium described in embodiments of this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having 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 thereof. In embodiments of this disclosure, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device. In embodiments of this disclosure, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. Program code contained on a computer-readable medium may be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0049] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device. The aforementioned computer-readable medium carries one or more computer programs, which, when executed by the electronic device, cause the electronic device to: Computer program code for performing the operations of embodiments of this disclosure can be written in one or more programming languages ​​or a combination thereof. Programming languages ​​include object-oriented programming languages—such as Java, Smalltalk, C++, and Python—and conventional procedural programming languages—such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0050] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0051] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A transparent software update method based on program entity activity modulation, characterized in that, include: The system acquires real-time status data and service dependency topology of software components, including CPU utilization, memory utilization, network throughput, and response time. Based on the trained prediction model and the current state data, the state data of the software component at the next moment is predicted to obtain the predicted state data. Based on the predicted state data, the activity level of each software component is calculated, and the state classification of each software component is determined. Based on service dependency topology, predicted state data, and state classification of each software component, update decisions are output through request analysis, window scoring, and sequence planning; the update decisions include update time, update sequence, and resource requirements. Based on the update decision, a transparent update is performed.

2. The transparent software update method based on program entity activity modulation according to claim 1, characterized in that, The calculation of the activity level of each software component based on the predicted state data includes: Based on the predicted state data, activity scores for CPU utilization, memory utilization, network throughput, and response time are calculated using preset thresholds. The activity level of each software component is calculated using a weighted average based on preset weights and the activity score.

3. The transparent software update method based on program entity activity modulation according to claim 2, characterized in that, The determination of the state classification for each software component includes: If the activity level of a software component is greater than or equal to the first threshold, the software component is judged to be in a highly active state. If the activity level of a software component is greater than or equal to the second threshold and less than the first threshold, the software component is judged to be in a medium-active state. If the activity level of a software component is less than the second threshold, the software component is judged to be in a low-activity state.

4. The transparent software update method based on program entity activity modulation according to claim 1, characterized in that, The update decision, based on service dependency topology, predicted state data, and state classification of each software component, outputs through request analysis, window scoring, and sequence planning, including: Based on request analysis, determine the resource requirements for component updates; Generate candidate time windows within a preset time period; determine the update time from the candidate time windows based on the predicted state data; Based on the service dependency topology and the state classification of each software component, the update sequence is determined.

5. The transparent software update method based on program entity activity modulation according to claim 4, characterized in that, The process of determining the update time from the candidate time window based on the predicted state data includes: The update score of the candidate time window is calculated based on CPU utilization, memory utilization, network throughput, and window duration. The start time corresponding to the candidate time window with the highest update score will be used as the update time.

6. The transparent software update method based on program entity activity modulation according to claim 1, characterized in that, The process of performing a transparent update based on the update decision includes: Based on the resource requirements of the updated decision, perform resource reservation confirmation, traffic scheduling, and service level adjustment; Once resource reservations are confirmed, traffic scheduling is completed, and service level adjustments are made, a transparent update will be performed.

7. A transparent software update device based on program entity activity modulation, characterized in that, include: The acquisition module is used to acquire the status data and service dependency topology of software components in real time. The status data includes CPU utilization, memory utilization, network throughput and response time. The prediction module is used to train the prediction model; based on the trained prediction model and the current state data, it predicts the state data of the software component at the next moment to obtain the predicted state data. The determination module is used to calculate the activity level of each software component based on the predicted state data, and to determine the state classification of each software component. The output module is used to output update decisions based on service dependency topology, predicted state data, and state classification of each software component, through request analysis, window scoring, and sequence planning; the update decisions include update time, update sequence, and resource requirements; An execution module is used to perform a transparent update based on the update decision.

8. The transparent software update device based on program entity activity modulation according to claim 7, characterized in that, The determining module includes: The first calculation unit is used to calculate the activity scores of CPU utilization, memory utilization, network throughput and response time based on the predicted state data and through preset thresholds. The second calculation unit is used to calculate the activity of each software component based on preset weights and the activity score.

9. An electronic device, comprising: One or more processors; A storage device for storing one or more programs, which, when executed by one or more processors, cause the one or more processors to implement the transparent software update method based on program entity activity modulation as described in any one of claims 1 to 6.

10. A computer-readable medium having a computer program stored thereon, wherein, When the computer program is executed by the processor, it implements the transparent software update method based on program entity activity modulation as described in any one of claims 1 to 6.

Images