Adaptive voltage regulation method for notebook dynamic power management

Abstract

The present application belongs to the technical field of computer hardware, and discloses a self-adaptive voltage regulation method for dynamic power management of a notebook computer, comprising: collecting multi-source data, generating a state label, and constructing a four-dimensional situation map; analyzing the task correlation strength and load type through space-time correlation, generating double labels in combination with user behavior; dividing the component safety boundary and allocating multiple types of credit, then forming a DAO smart contract set by constructing a component node network; and formulating state flow rules in combination with the real-time load characteristics of the components; generating a voltage regulation parameter table in combination with a V-F curve, reconstructing a synchronous regulation group and generating a synchronous regulation group configuration table, then executing component voltage regulation and state flow, and generating a state flow completion signal; generating a parameter optimization scheme through three-level feedback, and deducing the expected effect of the quantization scheme to form an evaluation report; and executing the parameter optimization scheme and synchronously updating it to the previous link as a new benchmark.

Description

Technical Field

[0001] This invention relates to the field of computer hardware technology, and more specifically, to an adaptive voltage regulation method for dynamic power management of laptop computers. Background Technology

[0002] With the increasing prevalence of mobile office work, gaming, and other entertainment needs, laptops are facing increasingly stringent requirements for balancing performance, battery life, and heat dissipation. Traditional power management relies heavily on fixed strategies, which are difficult to adapt to dynamic load fluctuations, differences in hardware coordination, and personalized user needs. This results in low energy efficiency, a significant conflict between battery life and performance, and a lack of dynamic guarantees for timing safety and hardware stability.

[0003] Existing solutions often employ single-dimensional adjustment or static rule configuration: focusing only on the independent voltage and frequency adjustment of the CPU and GPU, lacking cross-component coordination mechanisms, which can easily lead to power supply fluctuations or coordination failures; there is a disconnect between safety boundaries and performance optimization, either excessively limiting performance to ensure safety, or pursuing performance while ignoring timing risks and power consumption exceeding limits; and there is a lack of scenario-based adaptive capabilities, making it difficult to balance performance priorities and energy-saving needs in different scenarios. Summary of the Invention

[0004] To overcome the aforementioned deficiencies of the prior art and to achieve the above objectives, the present invention provides the following technical solution: an adaptive voltage regulation method for dynamic power consumption management of laptop computers, comprising:

[0005] S1: Collect multi-source data from hardware components, OS tasks, and user behavior, preprocess to generate status labels, combine instantaneous time series data to construct a four-dimensional situation map; and generate dual labels of scenario and intent by analyzing the task correlation strength and load type through spatiotemporal correlation analysis and combining user behavior.

[0006] S2: Based on the four-dimensional situation map and dual labels, the component security boundary is divided and multiple types of credit are assigned. Then, by building a component node network, a DAO smart contract set is formed. Combined with the real-time load characteristics of the components, state transition rules are formulated.

[0007] S3: Based on the DAO smart contract set and state transition rules, combined with the VF curve, generate voltage adjustment parameter tables for different adjustment scenarios, reconstruct the synchronous adjustment group and generate a synchronous adjustment group configuration table, and then execute component voltage adjustment and state transition, and generate a state transition completion signal.

[0008] S4: Based on the state transition completion signal, generate parameter optimization scheme through three-level feedback, deduce and quantify the expected effect of the scheme, and form an evaluation report;

[0009] S5: Based on the evaluation report, implement the parameter optimization plan and update it to the preceding steps as a new benchmark.

[0010] Furthermore, the construction method of the four-dimensional situation map includes:

[0011] Collect multi-source data from hardware components, OS tasks, and user behavior, and synchronously collect instantaneous time-series data of components; perform data quantization and labeling preprocessing on all data to generate standardized status labels for components;

[0012] Establish a mapping between status tags and instantaneous time-series data, and integrate all data into a globally unified four-dimensional situation map based on power consumption, thermal, performance, and hardware health as the dimensional framework.

[0013] Furthermore, the method for generating the dual tags includes:

[0014] Based on the four-dimensional situation map, the task correlation strength is evaluated by spatiotemporal correlation analysis in the form of task groups, and the load type is divided by load-related status labels in the component performance dimension.

[0015] Simultaneously, based on user behavior data and status tags, the user's basic intent is inferred, and combined with task load characteristics and OS application information, the scenario type is matched.

[0016] Associate and map scene types with basic intents to generate scene-intent dual labels.

[0017] Furthermore, the method of dividing component security boundaries and assigning multiple types of credits includes:

[0018] Based on the four-dimensional situation map and dual tags, total power consumption, heat dissipation, battery and hardware security are used as safety boundary types to define the operating threshold of each component and form a set of safety boundary parameters.

[0019] At the same time, we will construct a multi-type credit allocation rule based on basic credit, performance credit and green credit, dynamically allocate credit resources, and form a credit allocation summary table.

[0020] Furthermore, the generation method of the DAO smart contract set includes:

[0021] Based on the security boundary parameter set and credit allocation summary table, combined with the hardware topology of the laptop and the real-time online status of the components, DAO nodes are initialized for each component and a component node network is built.

[0022] Initial contract terms are generated based on the pre-set contract template and the strength of the task association, and pushed to the component node network for consensus verification through voting by each component node.

[0023] The verified initial contract terms are solidified into a set of DAO smart contracts adapted to the current operating scenario.

[0024] Furthermore, the methods for formulating state transition rules include:

[0025] Based on the four-dimensional situation map and DAO smart contract set, and combined with the hardware dynamic response parameters provided by the OS, the real-time load characteristics of the components are extracted.

[0026] Define standardized component states that adapt to all scenarios, take the current component state to the target component state as the link, and formulate regular and emergency flow triggering rules based on real-time load characteristics to form state flow rules.

[0027] Furthermore, the method of generating voltage regulation parameter tables by combining VF curves and different regulation scenarios includes:

[0028] Based on state transition rules, security boundaries, and DAO smart contract set, combined with the VF curve and voltage regulation interface provided by OS, voltage regulation parameter tables are calculated and generated for two types of regulation scenarios: regular regulation and emergency regulation.

[0029] Based on the task group, and combined with the collaborative relationship between the component nodes in the DAO smart contract, the synchronous adjustment group is obtained by screening and reconstructing, and the voltage adjustment parameter table is integrated to form the synchronous adjustment group configuration table.

[0030] According to the synchronous adjustment group configuration table, adjustment commands are issued through the voltage adjustment interface to coordinate the adjustment of component voltage and frequency, generate adjustment completion signal and synchronously update component status label.

[0031] Furthermore, the method for generating the state transition completion signal includes:

[0032] After receiving the adjustment completion signal, based on the updated component status label and in conjunction with the hardware status control interface and status switching protocol provided by the OS, the execution status transition is divided into normal and emergency execution states:

[0033] Under normal execution, single component state switching and intra-group collaboration are performed synchronously; under emergency execution, a reduction action is forcibly triggered and the state is locked.

[0034] Then, through cross-layer state synchronization and verification, a state transition completion signal and component state summary table are generated.

[0035] Furthermore, the method of generating parameter optimization schemes through three-level feedback, deriving and quantifying the expected effects of the schemes, and forming an evaluation report includes:

[0036] After receiving the state transition completion signal, based on the voltage regulation parameter table, the records of state transition execution and synchronous regulation group coordination, a full-link parameter optimization scheme is generated through three levels of feedback: component-level correction of voltage regulation execution parameters, synchronous group-level optimization of coordination strategy, and rule-level iteration of state transition rules.

[0037] Furthermore, the expected execution effect of the parameter optimization plan is quantified by pre-set evaluation indicators, and user behavior preferences are quantified, which are then integrated into an evaluation report containing parameter optimization plan, expected effect evaluation, problem list and user preferences.

[0038] Furthermore, the method by which the execution parameter optimization scheme is synchronously updated to the preceding stages as a new baseline includes:

[0039] Based on the assessment report, combined with the security boundary parameter set and the real-time adaptation status of OS components, a parameter optimization scheme is executed.

[0040] The optimized parameters after execution are then synchronously updated to the corresponding preceding steps, serving as a new baseline to initiate the next round of iterations and form a closed loop.

[0041] The technical effects and advantages of the adaptive voltage regulation method for dynamic power management of laptops in this invention are as follows:

[0042] This invention focuses on dynamic power consumption management for laptops in multiple scenarios, realizing full-link intelligent management of scenario perception, collaborative adjustment, feedback optimization, and closed-loop evolution, mainly used to balance the three core requirements of performance, battery life, and security.

[0043] First, by collecting multi-source data to generate a four-dimensional situation map and scene-intent dual labels, load characteristics and user needs are accurately identified, providing a basis for differentiated adjustment and solving the problem of scene adaptation lag.

[0044] Secondly, a multi-dimensional decision-making system is built based on security boundaries, credit mechanisms, and DAO smart contracts. Security constraints are embedded in voltage regulation and state transitions to avoid risks such as overvoltage or undervoltage and timing violations, while credit incentives enhance the willingness of components to cooperate.

[0045] Then, the synchronous regulation group is reconstructed to achieve cross-component collaborative regulation. Regulation parameters are dynamically generated for both routine and emergency regulation scenarios, taking into account both regulation accuracy and response speed, and solving the energy waste and collaborative failure caused by independent regulation.

[0046] Next, optimization plans are generated through three levels of feedback: component level, synchronization group level, and rule level. The expected effects are quantified by combining historical data to ensure the rationality and pertinence of the optimization actions.

[0047] Finally, a closed-loop evolution is formed through solution implementation verification and prior benchmark updates, continuously adapting to changes in hardware status and user preferences, and achieving energy efficiency optimization throughout the entire life cycle;

[0048] This invention, through its multi-dimensional perception, collaborative execution, and iterative optimization architecture design, achieves dynamic adaptation and secure control throughout the entire process from data collection to parameter updates. It is applicable to various laptop scenarios, significantly improving energy efficiency, battery life, and hardware stability, while reducing the cost of manual intervention for users. Attached Figure Description

[0049] Figure 1 This is a flowchart illustrating the adaptive voltage regulation method for dynamic power consumption management of a laptop computer according to the present invention.

[0050] Figure 2 This is a schematic diagram of the process for generating a state transition completion signal in the adaptive voltage regulation method for dynamic power consumption management of a laptop computer according to the present invention.

[0051] Figure 3 This is a schematic diagram of the process for generating an evaluation report in the adaptive voltage regulation method for dynamic power management of a laptop computer according to the present invention. Detailed Implementation

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

[0053] Example 1

[0054] Please see Figures 1 to 3 As shown in this embodiment, the adaptive voltage regulation method for dynamic power management of a laptop computer includes:

[0055] S1: Collect multi-source data from hardware components, OS tasks, and user behavior, preprocess to generate status labels, combine instantaneous time series data to construct a four-dimensional situation map; and generate dual labels of scenario and intent by analyzing the task correlation strength and load type through spatiotemporal correlation analysis and combining user behavior.

[0056] It should be noted that this step is used to address the problem that traditional power management relies on fixed strategies and cannot dynamically identify load fluctuations (such as sudden load changes from office work to gaming), real-time hardware status (such as temperature rise and battery degradation), and implicit user needs (such as pursuing performance when plugged in and focusing on battery life when unplugged), resulting in a lack of targeted adjustments.

[0057] S2: Based on the four-dimensional situation map and dual labels, the component security boundary is divided and multiple types of credit are assigned. Then, by building a component node network, a DAO smart contract set is formed. Combined with the real-time load characteristics of the components, state transition rules are formulated.

[0058] It should be noted that this step is intended to address the existing technology's disconnect between security and performance (such as excessively limiting performance to prevent overvoltage), lack of component coordination rules (such as power supply fluctuations caused by asynchronous CPU and GPU adjustments), and lack of mechanisms to incentivize component coordination, resulting in both security risks and coordination failures.

[0059] S3: Based on the DAO smart contract set and state transition rules, combined with the VF curve, generate voltage adjustment parameter tables for different adjustment scenarios, reconstruct the synchronous adjustment group and generate a synchronous adjustment group configuration table, and then execute component voltage adjustment and state transition, and generate a state transition completion signal.

[0060] It should be noted that this step is used to address the problems of energy waste caused by traditional independent adjustment of single components (such as adjusting only the CPU frequency), static parameters being unable to adapt to emergency scenarios (such as high temperature requiring rapid derating), and the lack of a synchronization mechanism causing component coordination timeouts, which exacerbate performance loss.

[0061] S4: Based on the state transition completion signal, generate parameter optimization scheme through three-level feedback, deduce and quantify the expected effect of the scheme, and form an evaluation report;

[0062] It should be noted that this step is used to address the problem that existing technologies lack feedback loops, and fixed parameters cannot adapt to hardware degradation (such as battery capacity reduction) and changes in user habits (such as long-term plug-in use), resulting in a decrease in adjustment accuracy over time.

[0063] S5: Based on the evaluation report, implement the parameter optimization plan and update it to the preceding steps as a new benchmark.

[0064] It should be noted that this step is used to address issues such as the inability to adapt to dynamic scenarios that may lead to hardware degradation or changes in user habits over a long period.

[0065] The methods for constructing a four-dimensional situation map include:

[0066] Collect multi-source data from hardware, OS, and user terminals, and synchronously collect instantaneous time-series data of components;

[0067] Among them, the hardware data consists of multi-dimensional parameters of hardware components, including electrical parameters (such as voltage) and physical parameters of components such as CPU, GPU, and memory controller. Each component is equipped with a dedicated sensor array.

[0068] Physical parameter acquisition: Infrared temperature sensors are deployed in the core area to acquire three-dimensional temperature fields (core temperature, package temperature, heat sink temperature, etc.); micro strain gauges are embedded at the edges of the CPU and GPU chips to acquire stress values ​​of silicon materials and record stress changes caused by chip thermal expansion;

[0069] OS-side data consists of task data and resource allocation load characteristics related to the processes of the underlying operating system (OS, such as Microsoft Windows) running on the laptop itself.

[0070] Task data: Collect data such as PID (Process Controller), process priority, memory usage (physical memory, virtual memory), and I / O read / write frequency (disk, network) of all running processes through the OS kernel scheduler interface;

[0071] Load characteristic data: Data such as CPU instruction execution count and memory bandwidth utilization are collected through hardware performance counters (PMC);

[0072] By combining process-related data with load characteristic data, a mapping table of process ID, resource consumption, and load characteristics can be established to ensure that the resource consumption of each process is traceable.

[0073] User-side data refers to user behavior data generated by users' own operations on laptop-related devices, including basic behavior data and authorized attention data;

[0074] Basic behavioral data: Keyboard key frequency (number of keystrokes per unit time) and touch screen operation trajectory are collected through the input device driver; application foreground and background status, and on-top status are obtained through the window manager;

[0075] Authorizing attention data: A privacy authorization pop-up window needs to be displayed first (clearly stating that the data is only used for scene adaptation and does not store the original image). After the user authorizes, the facial orientation is collected through the front camera (e.g., facing the screen is judged as "focused", and deviating from the screen by more than 45° is judged as "distracted"). The image data is only processed locally as a status label.

[0076] Instantaneous timing data is obtained by embedding Digital Transmission Management Units (DTMUs) in critical CPU timing paths (such as ALU arithmetic units and register read / write paths) and critical nodes of the GPU rendering pipeline. This captures timing margins (i.e., the difference between actual timing and critical timing) and the number of instantaneous timing violations (the number of times setup and hold times are violated). If the number of instantaneous timing violations is ≥3 times / ms, it is automatically marked as a timing risk.

[0077] All collected data are first subjected to noise reduction processing; for example, the moving average filtering algorithm is used to filter instantaneous noise in voltage and temperature data, and outliers in user behavior data are removed (such as single key press duration > 1s is judged as a false touch and removed); for instantaneous time series data, the Kalman filtering algorithm can be used to predict the current value based on historical time series margin data and correct abnormal deviations caused by instantaneous jitter.

[0078] Then, after noise reduction, the data is quantized, and continuous data is quantized into discrete state labels according to a preset threshold to form standardized state labels for components, including electrical parameter labels, physical parameter labels, OS task labels and user behavior labels.

[0079] Among them, electrical parameter labels: for example, voltage fluctuation ≤ ±0.05V corresponds to voltage stability label, > ±0.05V and ≤ ±0.1V corresponds to slight voltage fluctuation label, and > ±0.1V corresponds to severe voltage fluctuation label;

[0080] Physical parameter labels: For example, based on the core temperature thresholds of 60℃ and 90℃, the core temperature is divided into normal temperature, high temperature and high temperature warning labels; based on the threshold range of 30MPa-50MPa, the silicon stress is divided into normal stress, high stress and stress risk.

[0081] OS task tags: categorize CPU and GPU utilization into high load, medium load, and low load tags;

[0082] User behavior tags: The frequency of keyboard and mouse operations is categorized into active, inactive, and idle users; user attention is categorized into focused and unfocused users based on the direction of facial orientation.

[0083] Convert all tagged data into a format of 16-bit quantization value + 8-bit tag code, for example, "voltage stable" corresponds to quantization value 0x0001 and tag code 0x01; add a timestamp and component ID to each data entry to ensure data traceability and relevance;

[0084] Establish an association mapping between component status labels and instantaneous timing data; traverse the status labels and instantaneous timing data of all hardware components, and generate a fused label of status and timing according to the association mapping, thereby realizing the binding of hardware status and timing safety;

[0085] For example, the hardware status label is: voltage stable + temperature normal, timing margin requirement is ≥1.0ns, timing violation threshold is ≤1 time / ms, and the associated result label is timing safe;

[0086] Based on the high-precision timestamps of DTMU, the timestamps of hardware, OS, and user terminal data are calibrated, grouped by timestamp, and each 1μs is a data block. The fusion labels of the status and timing of all components, OS task labels, and user behavior labels within the time block are integrated to form a unified time slice data set.

[0087] The framework integrates all data based on power consumption, thermal performance, performance, and hardware health.

[0088] Among them, the sub-indicators of the power consumption dimension are: real-time power consumption of each component (equal to instantaneous voltage × instantaneous current), total OS power consumption (equal to the sum of the power consumption of each component), and power consumption growth rate (equal to the difference between the current total power consumption and the total power consumption of the previous time block); the classification is quantified by the threshold segmentation method: total power consumption is mapped to low power consumption, medium power consumption and high power consumption; power consumption growth rate is mapped to rapid power consumption increase, stable power consumption and rapid power consumption decrease.

[0089] Sub-indicators of the thermal dimension: three-dimensional temperature field data (areas >60℃ are marked as hotspot areas); quantitative classification: the core maximum temperature is mapped to thermal safety, thermal normality, and thermal warning; the number of hotspot areas is mapped to multiple hotspots, single hotspot, and no hotspots;

[0090] Sub-metrics of the performance dimension: average utilization of CPU and GPU, average cache hit rate, etc.; Quantitative grading: CPU and GPU utilization is mapped to high-performance output, medium-performance output, and low-performance output; cache hit rate is mapped to high-performance, normal-performance, and inefficient performance.

[0091] Sub-indicators of hardware health dimension: average stress value of silicon material, number of timing violations, and voltage fluctuation amplitude; quantitative classification: combining silicon stress label, number of timing violations and voltage fluctuation to determine the current health status (good, average, risk); for example, silicon stress <30MPa + timing violation ≤1 time / ms + voltage fluctuation ≤±0.05V corresponds to good health;

[0092] The structure is time block × component ID × four-dimensional dimension × sub-indicator. It stores quantified values, hierarchical labels, and indexes associated with the original data. For example: "Time block 0001-CPU-Core1-Power consumption dimension-Total power consumption=45W-Grade=Medium power consumption";

[0093] Then, a heatmap and line chart fusion method is adopted, with the horizontal axis representing time (in milliseconds) and the vertical axis representing the component ID. The four dimensions are represented by different color channels, with the color intensity corresponding to the quantization value. Hot spots are marked with flashing, and time-series risks are marked with red dashed lines. Finally, a globally unified four-dimensional situation map is constructed.

[0094] The methods for generating double tags include:

[0095] Based on the four-dimensional situation map, the built-in spatiotemporal correlation analysis module is invoked to evaluate the correlation strength of tasks on a task-group basis. The core logic is as follows:

[0096] Extract the communication frequency (OS inter-process communication log), data sharing ratio (physical memory sharing size ÷ total memory usage), startup time interval (startup time difference ≤ 1s indicates strong correlation), and resource contention (number of times CPU time slices are contested in the same time period) of processes within the task group as evaluation parameters;

[0097] The correlation strength calculation method is as follows: First, all evaluation parameters are dedivided (standardized to the 0-1 range). Then, the correlation strength value is obtained by weighted summation. Values ​​> 0.6 are marked as strongly correlated task groups, 0.3-0.6 as weakly correlated task groups, and < 0.3 as uncorrelated tasks. A task group set is generated, and strongly correlated task groups (such as "video conferencing software + camera driver + audio driver") and core dominant tasks (such as video conferencing software as the dominant task in this group) are labeled. It should be noted that the weighting weights in the weighted summation are set and fine-tuned based on expert experience. Here, the default weights (in order) are 0.4, 0.3, 0.2, and 0.1.

[0098] Load types are categorized based on load-related status labels in conjunction with component performance dimensions, including CPU-intensive (e.g., CPU utilization ≥ 80% and GPU utilization < 40% (e.g., code compilation, data processing)), GPU-intensive (e.g., GPU utilization ≥ 80% and CPU utilization < 40% (e.g., AAA games, video rendering)), hybrid-intensive (e.g., both CPU and GPU utilization ≥ 60% (e.g., live streaming + game execution)), and IO-intensive (e.g., memory bandwidth utilization ≥ 70% or disk I / O throughput ≥ 500MB / s (e.g., large file copying, database query)).

[0099] At the same time, based on user behavior data and combined with load status labels, intent mapping rules are established to infer the user's basic intent.

[0100] The example intent mapping rules are as follows: User behavior label: active + focused; Hardware load status: high load (strongly related task group); Basic intent: efficient computation; Priority: high;

[0101] User behavior tags: Active + Inattentive; Hardware load status: Medium load; Basic intent: Balanced performance; Priority: Medium;

[0102] User behavior tags: Low battery (<20%) + Active; Hardware load status: Any load; Basic intent: Energy saving priority; Priority: Highest;

[0103] It should be noted that the low battery data comes from the OS's battery management interface and serves as a mandatory trigger condition for "energy saving priority," taking precedence over other behavioral characteristics.

[0104] By combining task load characteristics, OS application information, and component status tags, the scenario type is matched using a pre-built scenario matching library;

[0105] Example scene matching library:

[0106] Office scenario: Task group consists of "office suite + browser" + hybrid intensive + OS foreground application is Word / Excel, etc.;

[0107] Game scenario: The task group includes "game process + graphics card driver" + GPU-intensive + OS foreground is a game application;

[0108] Video scenario: The task group includes "video player + audio driver" + medium load + hardware thermal dimension is normal;

[0109] Standby scenario: User idle for ≥5 minutes + all processes are background services + low hardware load + OS screen brightness ≤30%;

[0110] Associate and map scene types with basic intents to generate scene-intent dual labels (e.g., "Office - High-efficiency computing" and "Game - High-efficiency computing").

[0111] It should be noted that this step uses a four-dimensional situation map as the core input. Through the autonomous analysis of the laptop's power consumption management, combined with the task and behavior data provided by the OS, a dual label that accurately reflects the "current operating scenario and the user's core needs" is generated, providing a scenario basis for the subsequent decision-making rule formulation.

[0112] Methods for defining component security boundaries and assigning multiple types of credits include:

[0113] Based on the dual tags of four-dimensional situation map and scene-intent, total power consumption, heat dissipation, battery and hardware security are used as security boundary types to define the operating threshold of each component and form a set of security boundary parameters.

[0114] The total power consumption boundary is defined as follows:

[0115] The criteria for judgment are the laptop's rated TDP (thermal power design power) and the real-time total power consumption in the dual-label and four-dimensional situational graphs.

[0116] Dynamic adjustment rules: Preset power consumption limit coefficients for different scenarios, for example, 1 for high-efficiency computing scenarios, 0.8 for scenarios with balanced performance or stability priority, and 0.6 for scenarios with energy saving or low power consumption; then match the corresponding power consumption limit coefficient according to the current scenario type, multiply it with the rated TDP to calculate the total power consumption boundary;

[0117] Allocation logic: The total power consumption boundary is divided into each component according to the component's load contribution (current component power consumption ÷ total power consumption) (e.g., if the CPU load accounts for 50%, then the CPU power consumption boundary = total power consumption boundary × 50%).

[0118] Delineation of heat dissipation safety boundaries:

[0119] The criteria for judgment are the three-dimensional temperature field of the four-dimensional situation diagram and the rated power of the laptop's heat dissipation module;

[0120] Threshold settings: The upper limit of the core junction temperature = the hardware rated value (e.g., 95℃), and the upper limit of the package temperature is reduced by a certain percentage (e.g., 10%) based on the hardware rated value as the heat dissipation boundary; the power consumption boundary of components in hot spot areas is further reduced by 10% to avoid local overheating.

[0121] Battery safety boundary delineation:

[0122] The criteria for judgment are the laptop's battery health data (internal resistance, capacity degradation rate) and current SOC (remaining battery power).

[0123] Example preset constraint rules: Internal resistance > 200mΩ (aged battery): Limit total power consumption ≤ Rated TDP × 0.5, prohibit components from operating at full load; SOC < 10%: Trigger emergency power saving, total power consumption boundary = Rated TDP × 0.4, only ensure the operation of OS core services and current foreground tasks;

[0124] Charging status: During charging, the total power consumption boundary can be increased to 1.05 times the rated TDP (using charging power redundancy), while during discharging, the power consumption limit corresponding to the scenario is strictly followed;

[0125] Hardware security boundary delineation:

[0126] The criteria for judgment are the hardware rated parameters of the laptop and the current health status of the hardware health dimension of the four-dimensional status map;

[0127] Example threshold settings: CPU and GPU voltage limit = hardware rated voltage, reduced to 0.95 times when the health label is at risk; frequency limit = hardware rated frequency, reduced to 0.9 times when there is stress risk; memory bandwidth limit = hardware rated bandwidth, reduced to 0.9 times when there is timing risk.

[0128] Construct a multi-type credit allocation rule based on basic credit, performance credit, and green credit. Total credit = rated TDP × 100 (e.g., 150 WDP corresponds to 15,000 credits). Basic credit accounts for 70% of the total credit, and performance credit and green credit together account for the remaining 30% of the total credit. Generate a credit allocation summary table, including component ID, basic credit, performance credit, green credit, and total component credit (the sum of the three types of credit for the component).

[0129] Specifically, basic credit allocation (ensuring basic operation): the allocation is based on the coreness of the components (CPU cores > GPU units > memory controllers > peripherals) and the OS services' dependence on each component;

[0130] Allocation rules: CPU cores account for 40% of the base credit, evenly distributed among each core; GPU units account for 32%, evenly distributed among all GPU units; memory controllers account for 8%; peripherals (screen, wireless, storage) account for 20%; the characteristic is that the allocation is fixed and does not change with the scenario, ensuring the basic functions of the components operate;

[0131] Performance credit allocation (incentivizing high-efficiency computing): Allocation criteria: task priority (OS critical > user interaction > background service), load type, and operating scenario (high-efficiency computing has the highest priority).

[0132] Allocation Rules: High-efficiency computing scenarios + user interaction tasks + corresponding intensive components: An additional 30% of the base credit is allocated (e.g., in GPU-intensive game scenarios, each GPU unit receives an additional 30% of its own base credit; for example, if each GPU unit originally had 600 credits, it now receives an additional 180 credits); Balanced scenarios + mixed intensive tasks: An additional 15% of the base credit is allocated; Energy-saving scenarios + background services: No additional performance credit allocation; Features: Dynamic adjustment, tilting towards core tasks and components to incentivize performance improvement;

[0133] Green credit allocation (incentivizing energy-saving optimization): Allocation basis: Component energy efficiency ratio (performance output in the last hour ÷ power consumption), current power control effect (actual power consumption ≤ allocation boundary).

[0134] Allocation rules: When the energy efficiency ratio is ≥1.2 (above average level), an additional 20% of the basic credit is allocated; when the actual power consumption is ≤80% of the allocation boundary (significant energy saving effect), an additional 10% of the basic credit is allocated; for high-energy-consuming components (energy efficiency ratio <0.8), no green credit is allocated, forcing energy saving; Features: strongly tied to energy efficiency, guiding components to optimize power consumption within the safe boundary;

[0135] It should be noted that performance credits and green credits are allocated from the elastic credit pool (i.e., the total credit amount that is not allocated to basic credits) according to rules, to ensure that the total limit is not exceeded and to ensure that global resources are controllable.

[0136] The methods for generating DAO smart contract sets include:

[0137] Based on the security boundary parameter set and credit allocation summary table, as well as the laptop hardware topology data provided by the OS (such as the physical connection relationship between the CPU core and the memory controller) and the real-time online status of components (including running, standby, and fault, from the OS's device management module).

[0138] Initialize DAO nodes for each component to form node collaboration relationships: Assign a unique DAO (Decentralized Autonomous Organization) node identifier to each component, build a component node network based on the hardware topology, and mark the communication priority between nodes (based on the strength of task association, with the highest priority for communication within strongly associated components); synchronize the threshold of the security boundary, its own credit limit, and associated nodes to the corresponding component nodes to ensure that each node has access to global constraints and local collaboration object information;

[0139] Based on a pre-set contract template, initial contract terms (strongly bound to credit resources) are generated by combining the operational scenario and the strength of task relevance. These terms are divided into three core categories, including:

[0140] Credit Transaction and Lending Terms: Scenario-based exchange rates are set based on the flexible credit pool allocation ratio (performance credit to basic credit exchange rate is 1:1.2 for high-efficiency computing scenarios (1 unit performance credit can be exchanged for 1.2 units basic credit), and green credit to basic credit exchange rate is 1:1.3 for energy-saving scenarios). Transactions within strongly correlated component groups enjoy a 10% exchange rate discount. Components can borrow from associated nodes (loan amount ≤ 50% of their own basic credit, period ≤ 100ms). Interest = loan amount × scenario interest rate (e.g., 5% for high-efficiency computing scenarios, 3% for energy-saving scenarios). Interest is automatically deducted from the credit subsequently obtained by the borrowing component. For components that fail to repay on time, 50% of their performance credit will be frozen until the principal and interest are fully repaid.

[0141] Load Collaboration Responsibilities: Strongly correlated task groups designate a leading node (e.g., the video encoding component in a video conferencing scenario). The leading node allocates sub-tasks according to each node's credit limit and current load (assigned nodes must strictly adhere to security boundaries). Idle components (load ≤ 20%) must open a certain percentage (e.g., 10% to 30%) of redundant resources to associated nodes (e.g., opening 20% ​​bandwidth when the memory controller is idle). Opening resources will earn green credits paid by the leading node (e.g., 50 units of green credits for every 10% of resources shared). If a component reaches a security boundary while performing collaborative tasks, a collaboration interruption request can be triggered immediately, and the leading node must reassign tasks to avoid hardware damage.

[0142] Conflict handling and arbitration clauses: Select high-credit nodes (total component credit ≥ 1.2 times the average level, no default record) as arbitration nodes (3-5 nodes per scenario, dynamically rotating with a term of 100ms); when there is a conflict between components (such as credit transaction disputes, task allocation disagreements), submit to the arbitration node, the arbitration node retrieves historical data and contract terms, and makes a judgment through lightweight BFT consensus (a judgment is valid if more than half of the arbitration nodes agree); for nodes that violate the contract terms, deduct 10%-20% of green credit, and if the circumstances are serious (such as causing collaborative task failure), freeze the performance credit allocation permission for 1 second;

[0143] The generated initial contract terms are pushed to all component nodes. Component nodes vote based on their own interests, security compliance, and collaboration feasibility (if the terms meet the requirements and do not affect collaboration, they vote in favor). The voting weight is linked to the node's credit (e.g., credit ≥ 2000 units is weighted at 1.5, 1000-2000 units at 1.0, and < 1000 units at 0.5). The voting results are weighted according to the voting weight (i.e., a voting weight of 1.5 means 1.5 votes are cast). If the approval rate of the weighted voting results exceeds two-thirds (i.e., the ratio of weighted approval votes to the total weighted votes is ≥ 67%) and the approval rate of nodes in the strongly related task group is ≥ 80%, the initial contract terms are considered approved.

[0144] If the vote fails, the opposed clause is extracted and modified in conjunction with the objections before being revoked (up to 3 iterations). If it still fails, the basic contract is forcibly generated based on the safety boundary priority principle (to ensure that the laptop does not crash).

[0145] The approved terms are solidified using component ID-term type-effective scenario-validity period as an index, forming a set of DAO smart contracts adapted to the current scenario.

[0146] The ways to define state transition rules include:

[0147] Based on the four-dimensional situation map and DAO smart contract set, as well as dual tags, load type, task group set, security boundary parameter set, and credit allocation summary table, and combined with the hardware dynamic response parameters (CPU / GPU frequency-power consumption adjustment latency, etc.) and foreground task priorities (from the OS process scheduler, such as high priority for game processes and low priority for background services) of the laptop obtained by the OS through the firmware interface.

[0148] Data was aggregated at a frequency of 100μs, and three types of real-time load features were extracted, including: load intensity features (current hardware load value), scene matching features (dual labels + foreground task priority), and collaboration association features (load synchronization rate of strongly associated component groups).

[0149] Based on the principle of balancing safety, energy efficiency, and performance, four standardized component states are defined that match the hardware response parameters provided by the OS (covering the operating scenarios of all hardware components):

[0150] Lightly Ready State: Adapted for low-load + low-user activity or energy-saving scenarios, prioritizing energy saving, core parameters (taking CPU as an example) frequency = 50% of rated value, voltage = 60% of rated value, cache portion in hibernation;

[0151] Ready state: Adapted for medium load + balanced or office scenarios, with balanced energy efficiency. Parameters are: frequency = 70% of rated value, voltage = 80% of rated value, and cache fully activated.

[0152] Heavy Ready State: Adapted for high-load + high-efficiency computing scenarios or high-priority tasks, with performance as the priority. Parameters are: frequency = 100% of rated value, voltage = 100% of rated value, and performance maximized.

[0153] Emergency derated mode: Adapts to trigger safety boundaries, prioritizes safety, with parameters of frequency = 30% of rated value, voltage = 50% of rated value, and non-core functions disabled;

[0154] Based on real-time load characteristics and security boundaries, formulate state transition rules for regular triggering and emergency triggering;

[0155] The standard workflow rules (based on real-time load and scenario) define the link from the current component state to the target component state, specifying the required real-time load threshold, scenario conditions, credit constraints, and collaboration requirements. Example:

[0156] Lightly Ready to Ready (Transition Link): Real-time load threshold: load 40%-60% with fluctuation ≤±5%; Scenario conditions: balanced or office scenario + active foreground tasks; Credit constraint: total component credit ≥1000 units; Collaboration requirements: strongly related components synchronously upgrade to the ready state;

[0157] Ready state to heavily ready state: Load > 60% for 2 consecutive sampling points, high-efficiency scenario or high-priority task, total component credit ≥ credit high threshold (e.g., 2000 units), dominant node triggers synchronous transition within the group;

[0158] From ready state to ready state: 40%-60% load with no high-priority tasks, any scenario, no credit constraints, and synchronous degradation of components within the group;

[0159] From ready state to light ready state; when the load is <40% for 3 consecutive sampling points, in energy-saving scenarios or when the user is idle, without credit constraints, and when non-core peripherals are simultaneously reduced to light ready state;

[0160] The component state transition process must match the hardware response parameters (e.g., the CPU frequency increase time from ready state to heavily ready state ≤ 10μs) to avoid abnormalities caused by untimely hardware response.

[0161] Emergency workflow rules (based on security boundaries, highest priority): trigger conditions are directly associated with the component's status label (no scenario matching required, enforced). Example:

[0162] Arbitrary state to emergency de-rating state: High temperature warning, stress risk, timing risk, or emergency energy saving are possible;

[0163] Emergency derated state to light ready state: normal temperature and stress, no high load and no emergency energy saving;

[0164] During emergency transfer, the leading node must notify all components in the group. Nodes that fail to respond in a timely manner (e.g., 0.5μs) will have 20% of their green credits deducted (based on the penalty rules of the DAO smart contract).

[0165] When regular flow rules conflict with emergency flow rules (such as high temperature triggered in high-efficiency scenarios), the emergency rules are enforced. When there is a conflict in the state flow requirements between components (such as the CPU needing to ascend and the GPU needing to descend), the arbitration node designated by the DAO smart contract retrieves the real-time load characteristics and prioritizes the high-priority tasks (such as prioritizing the GPU in game scenarios).

[0166] Based on the VF curve, the methods for generating voltage regulation parameter tables for different regulation scenarios include:

[0167] Based on the four-dimensional situation map, dual labels, load type, security boundary, credit allocation summary table, DAO smart contract set, and state transition rules, the system also obtains hardware VF curves (voltage-frequency correspondence of each core of CPU and GPU), voltage regulation interface protocols (such as Intel VR13.0), and component driver response latency (time taken for voltage regulation commands to be issued to hardware to take effect) through the OS.

[0168] First, the data is checked for compatibility between the rules and the hardware: the voltage and frequency requirements of the target component state are compared with the VF curve provided by the OS to ensure that the adjustment parameters are within the range supported by the hardware. If they are out of range, they are automatically corrected to the maximum value of the hardware and 10% of the component performance credit is deducted.

[0169] Based on the data after adaptation and verification, voltage regulation parameter tables are calculated and generated for two types of adjustment scenarios.

[0170] Among them, the calculation of voltage regulation parameters for conventional regulation scenarios (adapted to non-emergency scenarios):

[0171] The calculation logic is as follows: extract the reference voltage corresponding to the frequency of the target component state from the VF curve, and combine it with timing margin correction (≥1.0ns (timing safety) to lower the reference voltage by 0.02-0.05V (energy efficiency optimization), 0.5-1.0ns (mild timing warning) to maintain the reference voltage, <0.5ns (timing risk) to raise the voltage by 0.01-0.03V (timing compensation)).

[0172] Then, the voltage reduction will be implemented according to the credit threshold constraints (for components with total credit ≥ high credit threshold, the voltage reduction will be implemented in full according to the adjusted voltage; for components with total credit in the threshold range (e.g., between 1000 and 2000 units), the voltage reduction will be halved; for components with total credit < low credit threshold, voltage reduction will be prohibited (only the base voltage will be maintained)).

[0173] The final voltage value must be ≤ the upper limit of the safety boundary and ≥ the minimum stable voltage of the hardware provided by the OS to avoid the risk of overvoltage or undervoltage.

[0174] Calculation of voltage regulation parameters for emergency regulation scenarios (adapted to emergency derating scenarios): The triggering condition is the emergency flow rule; Calculation logic: No VF curve matching is required, and the parameters are directly executed according to the emergency derating state. The priority is higher than that of regular regulation to ensure rapid cooling or energy saving.

[0175] To avoid collaborative failures caused by individual component flow, a synchronization adjustment group is obtained based on task groups and combined with the component collaboration screening and reconstruction of DAO smart contracts: The group is formed by using the dominant node in the state transition rules as the core, associating strongly related components, and eliminating irrelevant components (such as peripherals, low-load, and other non-related components); the adjustment order is marked (core nodes adjust first, and related nodes follow with a 0.1μs delay) to avoid power fluctuations caused by simultaneous adjustments; the voltage adjustment parameter table and the synchronization adjustment group are integrated to generate a synchronization adjustment group configuration table, including the synchronization adjustment group ID, core node, list of components within the group, adjustment order, and collaboration threshold; Example: Synchronization group ID = GPU-001, core node = GPU-Unit5, members = CPU-Core2 + memory controller, adjustment order = GPU first, then CPU, and finally memory, collaboration threshold = adjustment completion time difference ≤ 0.5μs;

[0176] According to the synchronous adjustment group configuration table, the adjustment command is issued through the OS voltage adjustment interface, including: target voltage, frequency, and execution time window (e.g., complete within 10μs).

[0177] OS drives hardware to work together (CPU and GPU adjust the power supply voltage according to instructions through built-in voltage regulators (VRM), frequency synchronously follows the VF curve to match, and the adjustment progress is reported back in real time).

[0178] After adjustment, initiate a three-level verification, including:

[0179] Voltage and frequency compliance: The error between actual and target values ​​is ≤ ±0.01V (voltage) and ±0.1GHz (frequency); Timing safety: Timing margin ≥ 0.5ns; Power consumption compliance: The power consumption of the adjusted component is ≤ the power consumption safety boundary;

[0180] If the verification result is not up to standard (e.g., voltage only rises to 1.15V, target 1.2V): reissue adjustment command, if still not up to standard, deduct 20% of the component's green credit; if timing violation (e.g., timing margin is 0.3ns after adjustment): increase voltage (e.g., increase by 0.03V), and simultaneously reduce frequency (e.g., reduce by 0.2GHz) until timing is safe; if power consumption exceeds standard (e.g., CPU power consumption reaches 25W, boundary 20W): trigger emergency derating, voltage is reduced and frequency is reduced simultaneously;

[0181] After the verification is passed, the adjustment result is recorded, an adjustment completion signal is generated, and the component status label is updated synchronously.

[0182] The methods for generating the state transition completion signal include:

[0183] Based on the adjustment completion signal and the updated component status label, the current running status feedback of the component (such as "lightly ready state - running") and the state switching protocol (such as CPU cache start / stop instruction set) are obtained through the hardware status control interface provided by the OS. The transition conditions are pre-verified: it is determined whether the adjustment results of voltage and frequency meet the parameter requirements of the target component state. If not, a rollback mechanism is triggered (only one rollback is allowed to avoid infinite loop), and the voltage adjustment parameters are recalculated.

[0184] After the pre-verification is passed, the state transition is executed in two categories: routine execution and emergency execution (ensuring that the transition actions are strongly linked to the component status and voltage regulation results):

[0185] Routine execution: Synchronously execute single component state switching and intra-group collaboration;

[0186] Single component state transition: Based on the target component state according to the state transition rules, issue state-related instructions containing hardware actions through the OS hardware control interface (e.g., from lightly ready state to ready state: issue "cache full activation + core voltage stabilization instruction").

[0187] Intra-group collaborative synchronization: The leading node synchronizes in reverse order of adjustment (e.g., the order is GPU first, then CPU, then memory during adjustment, and the reverse during flow synchronization). The state switching result is confirmed through the inter-component communication interface specified by the DAO smart contract (avoiding OS relay and reducing latency), ensuring that the time difference for component state switching is minimized.

[0188] Emergency Execution: Forcefully trigger the deduction action and lock the status;

[0189] Forced frequency reduction action: When the four-dimensional situational map detects emergency conditions such as "temperature ≥ 90℃" and "SOC < 10%" (even if voltage regulation is not completed), an emergency throttling command is issued to bypass the verification; the OS driver executes actions according to the safety priority principle: first shut down non-core hardware (such as wireless modules and external interfaces), then forcibly reduce the CPU and GPU frequencies to 30% of their rated values ​​and the voltage to 50% of their rated values, and finally freeze background non-core processes (only retaining OS core services and current foreground tasks);

[0190] State locking mechanism: After emergency transfer, the component state is locked to emergency derating state, which requires three conditions to be met: normal temperature, no high load, and no emergency energy saving. Only after the arbitration node verifies and passes the verification can the normal transfer permission be unlocked.

[0191] After the process is executed, cross-layer state synchronization and verification are carried out, including three-layer state synchronization and eventual consistency verification.

[0192] The system involves three layers of state synchronization: First, hardware layer synchronization: the OS writes the current actual operating state of the component into the hardware register and updates the four-dimensional situation map; second, power management layer synchronization: the final state label (including flow time and credit reward / penalty records) is updated to the four-dimensional situation map and stored in the local log; third, OS monitoring layer synchronization: the final state of the component + security label (such as "re-ready state - safe" and "emergency derating state - warning") is synchronized to the OS for the OS to display the power consumption mode (such as Windows "high performance mode"), and the state modification permission is not granted.

[0193] Final consistency verification: Compare whether the target component state, the actual component state executed by the OS driver, and the state collected by the four-dimensional situation map are consistent; if a state deviation occurs (e.g., the target is ready, but the actual state is light ready), reissue the state calibration command and deduct 15% of the green credit; if the deviation lasts for ≥3 sampling periods, trigger the subsequent rule optimization process.

[0194] Finally, the synchronization adjustment group ID and verification results are integrated to generate a state transition completion signal, and the state is synchronized to the OS to adapt to application resource allocation.

[0195] The methods for generating parameter optimization schemes through three-level feedback, deriving and quantifying the expected effects of the schemes, and forming an evaluation report include:

[0196] After receiving the state transition completion signal, the data is cleaned by combining the voltage regulation parameter table, the execution log records of the state transition and synchronous regulation group, the four-dimensional situation diagram, the safety boundary parameter set, the state transition rules and the credit reward and punishment records of the DAO smart contract: removing abnormal data such as extreme values ​​of emergency regulation and invalid records of temporary sensor failures, and aligning the time sequence of all data (ensuring that the data within the sampling period correspond one-to-one).

[0197] After data cleaning, a three-level feedback mechanism is used to generate a full-chain parameter optimization scheme, which includes:

[0198] Component level: The goal is to correct the execution parameters of voltage regulation and state switching in order to reduce the expected execution error;

[0199] Specific steps: First, calculate the error rate between the target value and the actual value of the component (e.g., CPU reready state voltage error rate = |1.2V - 1.18V| ÷ 1.2V ≈ 1.67%); then, for components with an error rate ≥ 5%, propose a VF curve adaptation parameter fine-tuning suggestion (fine-tuning with the minimum adjustment range, e.g., adjusting the CPU 4.8GHz base voltage from 1.2V to 1.21V); finally, combining credit reward and punishment records, for high-frequency default components (identified by threshold segmentation, e.g., memory controllers that frequently adjust timeouts), formulate a credit constraint threshold relaxation scheme (relaxed by a preset ratio, e.g., from ≥ 1000 units to ≥ 800 units), balancing accuracy and stability expectations;

[0200] Synchronization group level: The goal is to optimize the collaboration strategy to reduce the expected collaboration timeout rate;

[0201] Specific operations: First, calculate the average time difference between the completion of the synchronous adjustment group. For groups with a timeout rate ≥10%, adjust the adjustment order (e.g., adjust memory first, then CPU) or the delay interval (e.g., increase from 0.1μs to 0.15μs). Finally, for groups with inefficient shared resources, optimize the green credit reward coefficient (e.g., increase from 50 units per 10% of resources to 60 units) to enhance the incentive effect of DAO smart contracts.

[0202] Rule-level: The goal is to iterate state transition rules to adapt to different scenarios and loads;

[0203] Specific steps: First, analyze the false trigger rate of state transitions (e.g., false triggering of the heavy ready state under light load), and correct the trigger-related thresholds (e.g., increase the trigger load of the heavy ready state from ≥80% to ≥85%). Then, optimize the emergency derating trigger logic (e.g., trigger frequency reduction only when the temperature is ≥90℃ and there are two consecutive sampling points to avoid false triggering due to instantaneous high temperature). Finally, embed the implicit needs of the user's scenario (e.g., reduce the trigger load from the light ready state to the ready state in an office scenario from 40% to 35%).

[0204] After the parameter optimization scheme is generated based on the three-level feedback, simulations are performed using historical data. The expected execution effect and areas for optimization are then quantitatively evaluated using three pre-defined evaluation indicators, including:

[0205] Performance metrics: Expected energy efficiency ratio improvement rate (percentage increase in performance and power consumption after implementation compared to before optimization), expected synchronous adjustment group coordination rate (percentage of expected times with time difference ≤ 0.5μs), and expected state transition response speed (average simulation time from trigger to completion).

[0206] Compliance metrics: Expected number of safety boundary violations (number of simulated voltage and temperature exceeding thresholds after solution implementation), expected frequency of credit rewards and penalties (average number of simulated rewards and penalties per 100 executions), and expected user manual correction rate (percentage of simulated OS mode overhauls after solution implementation).

[0207] Preference metrics: expected scenario preference matching degree (simulated value of the fit between the solution and user behavior, such as the matching rate of the performance priority strategy in game scenarios), expected weight adaptation satisfaction (0-10 score based on historical user feedback).

[0208] At the same time, the OS obtains user manual settings (such as user manual switching of power consumption mode, screen brightness and battery life settings, etc.) and scenario feedback data (such as high-load users accepting performance priority by default if they do not manually reduce the frequency). This data is quantified into a scenario-preference weight correspondence table (such as game scenario: performance weight 0.6, energy saving weight 0.3, response weight 0.1), and strong preference items are marked (such as long-term plugged-in use, the corresponding battery life weight is reduced by 20%).

[0209] The final integrated assessment report mainly includes: an overview of the expected implementation effect of the plan (a simulated list of compliant and non-compliant indicators), a detailed list of parameter optimization plans, a weight correspondence table of user preferences, and a list of issues to be fine-tuned (such as "the energy-saving weight in the office scenario still needs to be improved").

[0210] It should be noted that historical data simulation and extrapolation are implemented through a built-in lightweight time-series database (TSDB) and a simple rule engine (with a built-in scene matching algorithm):

[0211] Lightweight time-series databases (such as time-series extensions of InfluxDBLite and SQLite, or custom circular buffers) are specifically designed to store historical time-series data (such as 500+ scene records from nearly 1 hour, each record containing load values, voltage and frequency parameters, energy efficiency ratio, collaborative compliance rate, etc., with each record being approximately 100 bytes, requiring only 50KB of storage per hour, and being fully controllable).

[0212] The simulation process (entirely executed autonomously by the power management module):

[0213] Input: The generated parameter optimization scheme;

[0214] Scene matching: Query the "most similar historical records to the current scene" from TSDB (matching dimensions: scene label, load range, hardware status; matching algorithm uses Euclidean distance; calculation latency ≤ 0.1μs).

[0215] Effect Calculation: Based on the correlation between parameters and effects in historical records, deduce the expected effect of the optimization scheme; Example:

[0216] If historical data shows that "for every 5% reduction in the load triggered in the office scenario, the energy efficiency ratio improves by 3% and the response speed improves by 2μs", then the expected effect of the current solution (reduction of 5%) is "a 3% improvement in energy efficiency ratio and a 2μs improvement in response speed".

[0217] If historical data shows that "synchronization group delay increased from 0.1μs to 0.15μs, and coordination timeout rate decreased from 12% to 4%", then this pattern can be directly reused as the expected result.

[0218] Output: The expected three types of evaluation indicators.

[0219] The methods for implementing parameter optimization schemes and synchronously updating them to preceding stages as a new baseline include:

[0220] Based on the evaluation report, the power management module takes the lead, with the OS providing interface support to execute parameter optimization schemes and batch update voltage regulation parameters, state transition rules, and other content.

[0221] The OS driver sends update commands through the OS hardware interface, verifies whether the update content conforms to the real-time adaptation status of the components (such as the maximum supported frequency of the GPU, battery SOC, etc.), ensures that hardware limitations are not exceeded, and provides real-time feedback on the adaptation results.

[0222] After execution, safety verification and effect verification are performed in combination with the safety boundary parameter set: safety verification is used to ensure that the updated voltage, temperature and power consumption do not exceed the safety boundary, and effect verification is used to evaluate the resolution rate of pending issues in the report ≥ 85% (such as the collaboration timeout rate being reduced to the target value and preference adaptation meeting the standard).

[0223] If the verification fails, immediately roll back to the baseline state before optimization, and wait for the next cycle to implement it again;

[0224] Once the verification is successful, the parameters and rules implemented after the deployment will be updated synchronously to the corresponding preceding steps (safety boundaries, flow status rules, voltage parameters, etc.) as the new benchmark.

[0225] At the same time, the solution content and verification results are consolidated, and the next cycle of perception-decision-execution-optimization-implementation is launched to form a closed loop.

[0226] Example 2

[0227] This embodiment discloses an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the operation mode of the adaptive voltage regulation method for dynamic power management of a laptop computer provided above.

[0228] Since the electronic device described in this embodiment is the electronic device used to implement the adaptive voltage regulation method for dynamic power management of a laptop computer in this application embodiment, those skilled in the art can understand the specific implementation method and various variations of the electronic device in this embodiment based on the adaptive voltage regulation method for dynamic power management of a laptop computer described in this application embodiment. Therefore, how the electronic device implements the method in this application embodiment will not be described in detail here. Any electronic device used by those skilled in the art to implement the adaptive voltage regulation method for dynamic power management of a laptop computer in this application embodiment falls within the scope of protection of this application.

[0229] The above formulas are all dimensionless calculations. The formulas are derived from software simulations based on a large amount of collected data to obtain the most recent real-world results. The preset parameters and thresholds in the formulas are set by those skilled in the art according to the actual situation.

[0230] The above description is merely a preferred embodiment of the present invention, and the scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for users of ordinary technical skills, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. An adaptive voltage regulation method for dynamic power management of a notebook computer, characterized in that, include: S1: Collect multi-source data from hardware components, OS tasks, and user behavior, preprocess to generate status labels, and combine instantaneous time series data to construct a four-dimensional situation map; Furthermore, by analyzing the spatiotemporal correlation strength and load type of tasks, and combining user behavior, dual labels of scenario and intent are generated; The construction methods of the four-dimensional situation map include: Collect multi-source data from hardware components, OS tasks, and user behavior, and synchronously collect instantaneous time-series data of components; perform data quantization and labeling preprocessing on all data to generate standardized status labels for components; Establish a mapping between status tags and instantaneous time-series data, and integrate all data according to the framework of power consumption, thermal, performance and hardware health to construct a globally unified four-dimensional situation map; S2: Based on the four-dimensional situation map and dual labels, the component security boundary is divided and multiple types of credit are assigned. Then, by building a component node network, a DAO smart contract set is formed. Combined with the real-time load characteristics of the components, state transition rules are formulated. S3: Based on the DAO smart contract set and state transition rules, combined with the VF curve, generate voltage adjustment parameter tables for different adjustment scenarios, reconstruct the synchronous adjustment group and generate a synchronous adjustment group configuration table, and then execute component voltage adjustment and state transition, and generate a state transition completion signal. S4: Based on the state transition completion signal, generate parameter optimization scheme through three-level feedback, deduce and quantify the expected effect of the scheme, and form an evaluation report; The method of generating parameter optimization schemes through three-level feedback, deriving and quantifying the expected effects of the schemes, and forming an evaluation report includes: After receiving the state transition completion signal, based on the voltage regulation parameter table, the records of state transition execution and synchronous regulation group coordination, a full-link parameter optimization scheme is generated through three levels of feedback: component-level correction of voltage regulation execution parameters, synchronous group-level optimization of coordination strategy, and rule-level iteration of state transition rules. Furthermore, the expected execution effect of the parameter optimization plan is quantified by pre-set evaluation indicators, and user behavior is quantified by preference, which is then integrated into an evaluation report containing parameter optimization plan, expected effect evaluation, problem list and user preferences. S5: Based on the evaluation report, implement the parameter optimization plan and update it synchronously to the preceding stages as a new benchmark.

2. The adaptive voltage regulation method for notebook dynamic power management according to claim 1, wherein, The methods for generating the dual tags include: Based on the four-dimensional situation map, the task correlation strength is evaluated by spatiotemporal correlation analysis in the form of task groups, and the load type is divided by load-related status labels in the component performance dimension. Simultaneously, based on user behavior data and status tags, the user's basic intent is inferred, and combined with task load characteristics and OS application information, the scenario type is matched. Associate and map scene types with basic intents to generate scene-intent dual labels.

3. The adaptive voltage regulation method for notebook dynamic power management according to claim 2, wherein, The methods for defining component security boundaries and assigning multiple types of credit include: Based on the four-dimensional situation map and dual tags, total power consumption, heat dissipation, battery and hardware security are used as safety boundary types to define the operating threshold of each component and form a set of safety boundary parameters. At the same time, we will construct a multi-type credit allocation rule based on basic credit, performance credit and green credit, dynamically allocate credit resources, and form a credit allocation summary table.

4. The adaptive voltage regulation method for notebook dynamic power management according to claim 3, wherein, The methods for generating the DAO smart contract set include: Based on the security boundary parameter set and credit allocation summary table, combined with the hardware topology of the laptop and the real-time online status of the components, DAO nodes are initialized for each component and a component node network is built. Initial contract terms are generated based on the pre-set contract template and the strength of the task association, and pushed to the component node network for consensus verification through voting by each component node. The verified initial contract terms are solidified into a set of DAO smart contracts adapted to the current operating scenario.

5. The adaptive voltage regulation method for notebook dynamic power management according to claim 4, wherein, The methods for formulating state transition rules include: Based on the four-dimensional situation map and DAO smart contract set, and combined with the hardware dynamic response parameters provided by the OS, the real-time load characteristics of the components are extracted. Define standardized component states that adapt to all scenarios, take the current component state to the target component state as the link, and formulate regular and emergency flow triggering rules based on real-time load characteristics to form state flow rules.

6. The adaptive voltage regulation method for notebook dynamic power management according to claim 5, wherein, The method of generating voltage regulation parameter tables by combining VF curves and different regulation scenarios includes: Based on state transition rules, security boundaries, and DAO smart contract set, combined with the VF curve and voltage regulation interface provided by OS, voltage regulation parameter tables are calculated and generated for two types of regulation scenarios: regular regulation and emergency regulation. Based on the task group, and combined with the collaborative relationship between the component nodes in the DAO smart contract, the synchronous adjustment group is obtained by screening and reconstructing, and the voltage adjustment parameter table is integrated to form the synchronous adjustment group configuration table. According to the synchronous adjustment group configuration table, adjustment commands are issued through the voltage adjustment interface to coordinate the adjustment of component voltage and frequency, generate adjustment completion signal and synchronously update component status label.

7. The adaptive voltage regulation method for notebook dynamic power management according to claim 6, wherein, The generation methods for the state transition completion signal include: After receiving the adjustment completion signal, based on the updated component status label and in conjunction with the hardware status control interface and status switching protocol provided by the OS, the execution status transition is divided into normal and emergency execution states: Under normal execution, single component state switching and intra-group collaboration are performed synchronously; under emergency execution, a reduction action is forcibly triggered and the state is locked. Then, through cross-layer state synchronization and verification, a state transition completion signal and component state summary table are generated.

8. The adaptive voltage regulation method for notebook dynamic power management according to claim 7, wherein, The method for synchronously updating the execution parameter optimization scheme to the preceding steps as a new baseline includes: Based on the assessment report, combined with the security boundary parameter set and the real-time adaptation status of OS components, a parameter optimization scheme is executed. The optimized parameters after execution are then synchronously updated to the corresponding preceding steps, serving as a new baseline to initiate the next round of iterations and form a closed loop.

Images