Edge cloud cooperative central air conditioning load self-adaptive regulation method

Abstract

The application discloses a kind of edge cloud cooperation's central air conditioning load self-adapting regulation and control method, it is related to central air conditioning control technical field, including: edge controller gathers power, water temperature flow, key area temperature and meteorology, generates unresponsive baseline power curve and deliverable reduction envelope, forms deliverable capacity contract containing risk budget and recovery constraint;Contract and random salt value are generated commitment abstract reporting, cloud platform obtains trusted timestamp certificate solidification;In event, demand response instruction is feasible domain check, and out-of-bound generates degradation curve, according to control right arbitration mechanism and point position authority matrix executes rolling constraint control and forms evidence abstract chain;After event, contract and random salt value are disclosed, cloud recalculation verification and output settlement evidence package and update model version.The method can reduce settlement dispute and cloud data volume, improve process verifiable, traceable.

Description

Technical Field

[0001] This invention relates to the field of central air conditioning control technology, specifically to a method for adaptive load control of central air conditioning systems through edge-cloud collaboration. Background Technology

[0002] In large public buildings (office buildings, commercial complexes, hospitals, schools, hotels, etc.), central air conditioning typically uses centralized cold and heat sources and chilled water / cooling water systems as cold and heat sources. It provides cooling and heating in zones through air handling units, fan coil units, fresh air systems, and building automation systems. The electrical load is characterized by concentrated periods, significant influence from outdoor weather and occupancy, and the ability to be adjusted according to set temperatures and unit / pump / cooling tower operating parameters. With the promotion and application of demand response and virtual power plant services, central air conditioning loads are connected to the grid-side platform as adjustable load resources, with aggregators or master stations performing peak shaving and acceptance settlement during designated periods.

[0003] Existing technologies, such as Chinese patent document CN105258306A, disclose an automatic demand response device for a central air conditioning system. This device is deployed on the central air conditioning system side and between the central air conditioning system and the grid-side demand response server. It receives event information through a microprocessor, communication, and interface modules, selects strategies, and issues control commands to the unit. Chinese patent document CN111076371A discloses a dynamic demand response control method for central air conditioning. This control method collects current operating parameters, analyzes and judges the load regulation space, and implements the corresponding peak-shaving scheme through regulation commands before switching to normal operation. Chinese patent document C... N116753599A proposes a cloud-based central air conditioning load control system, including modules for real-time data acquisition, analysis and prediction, dynamic control, maintenance, and security reinforcement, for cloud-based data management and control; Chinese patent document CN116255729A proposes a method for quantifying the demand response capability of central air conditioning systems that considers user preferences, quantifying response capability by combining room thermal models and power operation models with user preference models; Chinese patent document CN114925968A proposes a demand response assessment method, using the average power curve calculated based on cumulative electricity consumption as a correction baseline, correcting the issued index values, and assessing the effectiveness of user response.

[0004] However, in the above application scenarios, the central air conditioning demand response control method represented by the Chinese patent document CN111076371A mainly focuses on load regulation during the event, while the response quantity acceptance method mainly focuses on calculating the load baseline and comparing the actual power based on the collected power data after the event.

[0005] Because the central air conditioning load is affected by factors such as outdoor weather, personnel occupation, equipment operating conditions and control switching, there are multiple sources of control on site, including building automation systems, cloud platform strategies and manual intervention, as well as communication anomalies or data loss. The baseline curve and response quantity calculation are inconsistent under different data calibers or different calculation methods, making it impossible to obtain a stable and verifiable acceptance basis. Therefore, disputes are likely to arise in the judgment and settlement of response effects in large-scale applications.

[0006] Even if Chinese patent document CN114925968A proposes a baseline correction approach, the corrected baseline may still deviate from reality due to changes in operating conditions and control switching. Summary of the Invention

[0007] (a) Technical problems to be solved

[0008] To address the shortcomings of existing technologies, this invention provides a cloud-edge collaborative method for adaptive load control of central air conditioning. It generates a non-responding baseline power curve and a deliverable reduction envelope to form a deliverable capacity contract containing risk budgets and recovery constraints. A commitment summary is generated and reported for the contract and a random salt value, and the cloud platform obtains and solidifies this summary with a trusted timestamp. During an event, feasible domain verification is performed on demand response instructions, and a degradation curve is generated if the limit is exceeded. Rolling constraint control is executed according to a control arbitration mechanism and a point-of-use permission matrix, forming an evidence summary chain. After the event, the contract and random salt value are revealed, and the cloud recalculates and verifies the data, outputting a settlement evidence package and updating the model version. This reduces settlement disputes and the amount of data uploaded to the cloud, thus solving the technical problems mentioned in the background art.

[0009] (II) Technical Solution

[0010] To achieve the above objectives, the present invention provides the following technical solution:

[0011] This includes: the edge controller collecting and verifying data, generating a non-responding baseline power curve, calculating the deliverable reduction envelope based on device protection constraints and comfort constraints, and forming a deliverable capacity contract containing risk budget and recovery constraints; the edge controller calculating a commitment summary of the deliverable capacity contract and random salt value and reporting it; and the cloud platform obtaining a trusted timestamp certificate for the commitment summary.

[0012] The cloud platform issues demand response instructions associated with the deliverability contract. The edge controller performs feasible domain verification. When the boundary is exceeded, an executable degradation curve is generated. Control is implemented according to the control arbitration mechanism and the point authority matrix, and an evidence summary chain is generated. After the event, the edge controller reveals the deliverability contract and random salt value. The cloud platform recalculates and compares the commitment summary and verifies the trusted timestamp certificate. Based on the non-response baseline power curve and the evidence summary chain, a settlement evidence package is generated, and the deliverability reduction envelope is updated based on the execution deviation.

[0013] Furthermore, the edge controller collects total power consumption, chilled water supply and return temperatures and flow rates, terminal critical area temperatures, outdoor weather conditions and time period types at a preset time before the demand response event begins. It performs time-series alignment, missing data completion, anomaly removal, and generates a data quality score. The data quality score, along with the event window, model version, and validity period, is written into the deliverability contract.

[0014] Furthermore, the non-response baseline power curve is obtained by the edge controller through weighted aggregation of historical total power consumption based on the set of sampling times. The weighting coefficients are jointly determined by data quality scores, outdoor weather conditions, and equipment combination status codes. The generated non-response baseline power curve is then written into the deliverability contract.

[0015] Furthermore, the equipment combination status code is obtained by concatenating the number of operating chiller units, the operating status of chilled pumps, the operating status of cooling pumps, and the operating status of cooling towers according to preset weights. The operating status includes start / stop status and frequency converter gear. The preset weights and gear division rules are written into the model version, and the equipment combination status code is associated with and saved with the sampling time set.

[0016] Furthermore, the edge controller calculates the upper and lower bounds of the deliverable reduction envelope based on device protection constraints, operating condition constraints, and comfort constraints in each time slice, and writes ramp capability and duration as time coupling parameters into the deliverable capability contract, where comfort constraints include the upper limit of critical area temperature.

[0017] Furthermore, the risk budget includes a comfort risk budget and an equipment operation budget. The comfort risk budget includes the allowable temperature drift range and the tolerance for exceeding limits, while the equipment operation budget includes the number of start-stop cycles and the cumulative frequency fluctuations. The recovery constraints include recovery slope limits and recovery peak limits, and are written into the deliverability contract.

[0018] Furthermore, the edge controller generates a contract normalization string from the deliverability contract according to field identifiers, fixed order and fixed point representation, generates a random salt value, calculates a commitment summary from the contract normalization string and the random salt value and reports it to the cloud platform, and securely saves the original deliverability contract and random salt value locally.

[0019] Furthermore, the length of the random salt value is 16 to 32 bytes; after receiving the commitment summary, the cloud platform applies for a trusted timestamp certificate from a third-party trusted timestamp service. The trusted timestamp certificate contains the issuance time and the issuer's signature, and the commitment summary and trusted timestamp certificate are associated to generate a binding code, which is stored in the commitment index and corresponds to the contract number.

[0020] Furthermore, the demand response instruction includes the target reduction curve, effective time window, ramp-up requirements, priority, and instruction integrity verification information; the edge controller verifies the validity of the deliverable capability contract referenced by the demand response instruction and performs feasible domain verification. When the deliverable reduction envelope is exceeded, an executable degradation curve that meets the envelope boundary and ramp-up requirements is generated and the reason for the out-of-bounds error is returned.

[0021] Furthermore, the edge controller sets up a control arbitration mechanism and a point permission matrix to limit the control quantities that can be written to the demand response, as well as their change range and holding time. When there is a conflict with safety protection, comfort hard constraints, energy-saving strategies, or manual writing, arbitration is carried out in the order of safety protection priority, comfort hard constraints priority, and demand response priority over conventional plans, and the arbitration result and cause are written into the process record corresponding to the evidence summary chain.

[0022] Furthermore, the edge controller executes rolling constraint control within a fixed control cycle. The rolling constraint control targets the power tracking deviation and writes comfort constraints, equipment protection constraints, and recovery constraints into the constraint conditions. It achieves an executable degradation curve by updating the chilled water outlet temperature setting, pump frequency range, cooling tower fan adjustment, and non-critical area setting values.

[0023] Furthermore, the process log includes measured power, corresponding values ​​of the non-responding baseline power curve, corresponding values ​​of the target reduction curve, actual control quantities, key status quantities, alarm information, arbitration flags, and degradation flags; the edge controller links the process logs one by one to generate an evidence summary chain according to the sampling period, and sends the latest summary of the evidence summary chain to the cloud platform every one to five sampling periods to obtain a reliable timestamp for solidification.

[0024] Furthermore, the edge controller reveals the original deliverability contract and random salt value to the cloud platform, which then recalculates and compares the commitment summary and verifies the trusted timestamp certificate to generate a settlement evidence package.

[0025] During dispute review, the cloud platform selectively discloses process records according to the dispute time window and provides evidence summary chain verification path, while the edge controller updates the model version based on execution deviation.

[0026] (III) Beneficial Effects

[0027] This invention provides a central air conditioning load adaptive control method with edge-cloud collaboration, which has the following beneficial effects:

[0028] Data collection and quality verification yield the non-response baseline power curve. Combined with equipment protection constraints, operating condition constraints, and comfort constraints, the deliverable reduction envelope is calculated, along with risk budgeting and recovery constraints to calculate the deliverable capacity contract. Before an event, the deliverable boundary constraints and recovery rebound can be determined by time slices. A commitment summary of the deliverable capacity contract is calculated using a random salt value and reported. Finally, a reliable timestamp certificate is obtained from the cloud platform for solidification. The contract can be recalculated and verified after an event without requiring the cloud platform to hold the original contract text, reducing privacy, settlement disputes, and maintaining consistency. Contract consistency and feasible domain verification are performed on demand response instructions. When an instruction exceeds the deliverable reduction envelope, an executable degradation curve is generated, and the out-of-bounds reason and executable range are returned. The execution target and feasible domain converge, reducing comfort complaints caused by over-issuance.

[0029] By limiting writable control quantities, their range of change, and duration of hold through control arbitration and point-of-use permission matrices, conflicts between safety protection, comfort hard constraints, demand response, and normal plans are written into the process log, enabling multi-source control to coordinate in a fixed order and facilitating traceability. Rolling constraint control updates effluent temperature, pump frequency range, and cooling tower fans, converging to near comfort levels or increased equipment risk with reduced convergence magnitude and including recovery constraints. Power tracking is consistent with equipment protection, comfort boundaries, and recovery processes. The system reveals verification recalculation comparison commitment summaries and trusted timestamp credentials, combining evidence summary chains to generate settlement evidence packages with selective disclosure support. Dispute reviews do not upload full original data. Baseline models and envelope margin parameters are updated based on execution deviations, creating an iterative closed loop for contract generation, event execution, and acceptance settlement. Attached Figure Description

[0030] Figure 1 This is a system architecture and overview block diagram of the present invention;

[0031] Figure 2 This is a schematic diagram illustrating the unified sampling time grid and spatiotemporal alignment of the present invention;

[0032] Figure 3 This is a schematic diagram of the missing / abnormal layered repair and data quality scoring process of the present invention;

[0033] Figure 4 This is a schematic diagram illustrating the generation of the non-response baseline power curve and the composition of the compatibility weights in this invention;

[0034] Figure 5 This is a schematic diagram illustrating the deliverable reduction envelope (upper / lower bound) solution and risk budget / restoration constraints of the present invention;

[0035] Figure 6 This is a flowchart of the instruction packet consistency check, envelope out-of-bounds determination, and continuous degradation curve generation process of the present invention. Detailed Implementation

[0036] 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.

[0037] Please see Figures 1-6 This invention provides a method for adaptive load control of central air conditioning systems based on edge-cloud collaboration.

[0038] Step 1: Before the demand response event begins, compress the multi-source operating data of the central air conditioning site into a pre-event dataset under the same time grid, and form a deliverable capacity contract based on it, so that subsequent steps can be consistently referenced around the same non-response baseline power curve and deliverable reduction envelope.

[0039] In public buildings, the total power consumption of central air conditioning systems varies with outdoor weather, terminal loads, and the configuration of equipment in the machine room. If a single reading is used to infer potential reductions before an event, it's easy to mistake data acquisition delays for load changes and transient reductions for sustainability commitments, leading to comfort boundary approaching or equipment protection triggering during the event. Step one uses deliverability as the constraint boundary, first ensuring the consistency and reliability of the collected input time, then solidifying the baseline power curve, reduction envelope, risk budget, and recovery constraints into a single contractual data object. This avoids discrepancies in subsequent stages and allows on-site personnel to see a verifiable and traceable commitment boundary before the event occurs.

[0040] Data acquisition links are typically distributed: electricity meters transmit data via meter reading gateways, computer room status is transmitted via building automation controllers, and terminal temperature data is transmitted via sensor gateways. These link differences can cause misalignments between recorded power and temperature values, which can easily be mistaken for system responses if modeled directly.

[0041] The edge controller first establishes a unified sampling time grid using a local clock, discretizing the pre-event observation period into a set of sampling times. Then, it records the message arrival time and the sampling time within the message for each acquisition channel, and limits the propagation delay range of that channel using round-trip delay measurements. Finally, it maps the sampling times to the most recent sampling time. To suppress long-term drift, the edge controller estimates the channel offset using a fixed window and performs segmented corrections, ensuring that the same channel falls within the same grid on different days. The sampling period of the unified grid is preferably between 30 seconds and 5 minutes to account for both communication jitter and device switching step effects.

[0042] The edge controller writes a time alignment field (channel identifier, nominal sampling period, maximum propagation delay, drift window) for each channel, and then aggregates the fields from different channels that fall into the grid at each sampling time. For continuous variable fields, if multiple sampling records fall into a grid, the records in the grid are aggregated according to the acquisition time to obtain the representative value of the grid. For discrete state fields, the state closest to the end of the grid at the acquisition time is taken as the representative state, and discarded state changes are written to the state change tracking field to avoid losing device switching information. Meteorological fields use the most recent value within the validity period, and a missing flag is written after the validity period expires.

[0043] A unified time grid stabilizes the correlation between power and temperature, reducing the probability of misinterpreting communication delays as load changes. Different grid convergence rules are used for continuous variables and discrete states, ensuring both the traceability of device switching and the continuity of temperature curves are maintained. In an alternative implementation, a controller with hardware time synchronization capabilities can be used as the time reference, but the data structure and time alignment fields recorded simultaneously remain unchanged.

[0044] Even after completing the simultaneous recording, missing segments and outliers may still appear: missing segments are mostly caused by short-term channel interruptions, while outliers are mostly caused by range exceeding limits, sensor drift, or device state jumps. Simply removing these segments will result in sparse samples, and simple interpolation will mask the true transitions caused by device switching, thus causing the baseline power curve to be incorrectly smoothed before the event.

[0045] The edge controller employs a tiered repair mechanism based on the length of missing values: short missing values ​​are repaired using piecewise cubic interpolation with range boundaries, with a preferred threshold of one to three sampling periods; medium missing values ​​are replaced using cross-channel conservation constraints, with a preferred threshold of four to twenty sampling periods; long missing values ​​are simply marked with a missing value without generating a replacement value, avoiding the masking of long time gaps with smoothing curves. For anomalies, range screening is performed first, followed by cross-channel consistency screening. Consistency screening considers whether power changes are supported by changes in equipment configuration and whether temperature changes are compatible with the direction of changes on the chilled water side. Screening results are written to the anomaly marker field. Subsequently, the missing markers, anomaly markers, and the degree of cross-channel inconsistency are summarized as a consistency breach cost. Furthermore, a saturation-type mapping is used to generate data quality scores, ensuring that the scores are discriminative in the high-quality range and decay rapidly in the low-quality range.

[0046]

[0047] Where: Consistency breach cost : Value The penalty for exceeding the range limit, the penalty for inconsistency across channels, and the penalty for missing markers are added together according to the field weights; saturation scale factor. : Value To control the rate of score decay, ensuring that minor abnormalities do not cause a sudden drop in score; sampling time The value range is the set of discrete moments in a uniform sampling time raster; data quality score. : Value This is used to determine the weight of the record in subsequent baseline and envelope calculations and to retain its trace value;

[0048] Let the number of fields be the number of fields. , No. The values ​​of all fields are the field values ​​at the same time. Its physical allowable range is the minimum range. With the maximum range Missing markers are missing markers (Take 0 or 1, where 1 indicates that the field is at the sampling time) (Missing or deemed unavailable). Define range out-of-bounds penalty as range penalty. Missing penalty is missing penalty Cross-channel consistency penalty is a consistency penalty. Then the cost of consistency breach is acceptable:

[0049]

[0050] Number of fields : Takes a positive integer value, used to enumerate the number of fields included in the quality assessment; field value The value can be a real number or an enumerated value within the range of this field, and its purpose is to serve as input for quality determination; minimum range. : Values ​​are real numbers, used to constrain the physical lower bound of the field and for calculating out-of-bounds penalties; Maximum range The value range is real numbers, and its function is to constrain the physical upper bound of the field and to be used for calculating out-of-bounds penalties;

[0051] Missing markers : Values Its function is to indicate the time of this field. Is it missing or unavailable; range weighting The value range is non-negative real numbers; its function is to set the field. The contribution of range out-of-bounds measurement to the overall cost of default; missing weights : Non-negative real numbers, used to define the field The contribution of the absence of [a certain element] to the overall cost of default; consistency weight. : A non-negative real number whose function is to define the contribution of cross-channel consistency penalty to the overall cost of default;

[0052] Consistency breach cost The range of values ​​is Its function is to quantify the degree of unbelievability of the records at the same moment and map it to... The range penalty and the missing penalty can be defined as follows:

[0053]

[0054] Range penalty : Values Its function is to measure fields. Amplitude exceeding the physical range; maximum function The value is a mapping to the larger value of the input real number, and its function is to truncate the out-of-bounds range to non-negative.

[0055]

[0056] Missing penalty The range of values ​​is Its function is to directly include the deficiency in the cost of breach of contract;

[0057] Cross-channel consistency penalties provide achievable power jump constraints in steady-state conditions. For example, in unchanging device combination state coding. The power should not exhibit abrupt changes that are inconsistent with the state. If the measured power is the actual measured power... Power jump threshold If the power jump threshold is set by the project or given by historical high-quality samples, then the following conclusions can be drawn:

[0058]

[0059] Where: consistency penalty : Values Its function is to penalize abnormal power jumps when the equipment combination state remains unchanged; measured power : Values Its function is to serve as a key input for consistency penalty; power jump threshold : Values Its function is to define the upper bound of acceptable normal fluctuations under unchanged conditions, which can be set by engineering experience or calculated from historical high-quality samples; Equipment combination state coding The value range is non-negative integers. Its function is to characterize the combined operation mode of the unit and the water system and to be used for consistency determination.

[0060] The edge controller writes the field value, field status, and field score into the pre-event dataset and categorizes the records at the same moment into modeling samples and trace samples based on a data quality score threshold determined by the on-site data quality requirements. For trace samples below the threshold, the edge controller does not participate in baseline and envelope calculations but retains their time alignment field and anomaly markers to verify after the event why a certain period was not used for commitment.

[0061] When used, tiered repair maintains data continuity, preventing subsequent baseline power curves from being broken due to short missing values, while avoiding unreliable substitutions for long missing values. Data quality scoring compresses multi-source anomalies into a single quantitative indicator, facilitating the explicit representation of risk budgeting and contraction logic in subsequent contract generation.

[0062] Furthermore, based on the pre-event dataset and data quality score, a non-response baseline power curve is generated, and the upper and lower bounds of the deliverable reduction envelope are calculated. At the same time, the comfort risk budget, equipment action budget, recovery constraint field, model version and validity period are written into the deliverable capability contract along with the curve and envelope, so that subsequent steps can refer to the same contract number to lock the caliber.

[0063] The baseline power curve needs to be verifiable and adaptable to daily conditions. Sampling only based on the same calendar will result in deviations during holiday transitions; similarly, sampling only based on outdoor temperature will lead to deviations due to changes in equipment configuration. Simultaneously, meteorological compatibility and equipment configuration compatibility are introduced to ensure the baseline comes from interpretable compatible segments. Data quality scores are used as a weighting factor to prevent low-quality samples from appearing similar in terms of compatibility but actually being distorted.

[0064] The edge controller first acquires data quality scores to obtain high-quality synchronous records, and then calculates the compatibility weighted convergence power within the historical window to obtain the baseline. The historical step count optimization time is linked to the sampling period. Historical step counts with a one-minute sampling period optimize compatibility segments within 24 hours; historical step counts with a five-minute sampling period optimize compatibility segments within two to three days. The day / night mode and weekday mode are as follows:

[0065]

[0066] Where: unresponsive baseline power : Value , used to represent the expected power at the sampling time without demand response control; compatibility weights : Value This is used to measure the comparability between the sampling time and historical times and for aggregation; measured power : Range of values Used to provide historical power samples and carry historical operating modes; historical steps : A positive integer used to limit the convergence window and control the smoothness and following of the baseline;

[0067] Sampling time : Values ​​are the discrete time set of a uniform sampling time raster, used for indexing baseline output; Historical Index : An integer ranging from 1 to 1, used to enumerate historical samples;

[0068] The compatibility weight adopts an exponential decay form for the differences in meteorological conditions and equipment combinations, so that the greater the difference, the smaller the weight and the continuity is maintained.

[0069]

[0070] Where: Data quality score : Range of values Its function is to reduce the credibility of historical samples;

[0071] outdoor temperature The value is a real number within the range of the on-site meteorological temperature measurement, representing the meteorological conditions and participating in compatibility judgment; equipment combination status. : A non-negative integer used to represent the combined code for the number of chillers, pump start / stop, pump frequency grading, and cooling tower operation grading. The coding rules are fixed in the contract generation configuration; meteorological attenuation coefficient. : is a positive real number used to adjust the sensitivity of outdoor temperature differences to weights, so that the baseline is not misled by sudden weather changes;

[0072] Equipment attenuation coefficient : A positive real number used to adjust the sensitivity of equipment combination differences to the weights, ensuring the baseline does not drift across operating modes; compatibility weights : Range of values Its function is to measure the current moment. With historical moments Comparability and its use in baseline aggregation; historical index : An integer ranging from 1 to 1, used to enumerate historical samples; sampling time : Values ​​are the set of discrete moments within a uniform sampling time grid, used to index the current sampling; historical moments The value is a set of discrete moments within a uniform sampling time grid, used to index the th historical sample;

[0073] When generating equipment combination status codes, the edge controller first converts the number of chillers, pump start / stop, pump frequency range, and tower fan range into fixed-length status fields, and then concatenates them into integer codes in a fixed order to avoid the same combination being mapped to different codes by different representation methods. Subsequently, when calculating compatibility weights, the data quality score is written as a reduction factor into the weight calculation configuration, so that low-quality samples will not dominate the baseline even if the weather is similar.

[0074] The baseline power curve is derived from a compatible segment and is linked to the equipment combination status, making it easy for on-site personnel to interpret the baseline source by comparing the number of chillers and pump frequencies on the building automation screen. The baseline output and the concurrent recording maintain the same sampling time set, providing an alignment reference for subsequent envelope reduction calculations.

[0075] The reduction envelope must not only meet the requirements of power availability, but also the requirements of comfort sustainability and equipment tolerance. The temperature margin and control action margin in critical areas are written into the same solution constraint, causing the upper limit of reduction to shrink as the margin changes. This shrinkage logic is then solidified into a risk budget field, avoiding the misinterpretation of transient states as commitments.

[0076] Among them, the edge controller extracts observable response segments from historical operation records. The response segment is defined as a continuous record before and after the control action occurs. The control actions include increasing the outlet water temperature setting, decreasing the pump frequency in stages, switching the number of chillers, and adjusting the set temperature of non-critical areas.

[0077] The edge controller groups response segments according to device combination states, obtaining a mapping table: under a given device combination state, the direction of power change caused by a unit control action, the direction of temperature drift in the critical area, and the drift duration characteristics. Subsequently, at each sampling time, the mapping table is used to calculate the consumption of critical area temperature and action margins under the candidate reduction magnitude, and a logarithmic barrier constraint is used to express the risk budget, ensuring that the barrier tightens rapidly when the margin approaches zero. Where:

[0078]

[0079] In the formula: upper bound of deliverable reduction : Value This is used to form the upper bound of the deliverable reduction envelope and incorporate it into the contract; candidate reduction magnitude. : Value This is used as a solution variable to find the maximum deliverable value that satisfies the risk budget; number of key areas : is a positive integer used to enumerate the critical regions included in the comfort constraints;

[0080] Control the number of actions : A positive integer used to enumerate control actions included in the motion budget; Temperature margin function : Value , is used to characterize the predicted margin of the i-th key area from the upper temperature limit during the contract duration under the reduction magnitude. The margin is calculated by the mapping table and varies with daily conditions.

[0081] Action margin function : Value This is used to characterize the remaining margin of the i-th control action relative to the upper limit of the action budget under the reduction magnitude; the margin is calculated from the equipment protection constraints; comfort risk budget. : Values ​​are real numbers used to limit the overall barrier level of temperature margin, preventing the comfort margin from being overdrawn; Equipment motion budget : Values ​​are real numbers, used to limit the overall barrier level of motion margin, preventing the motion budget from being overdrawn; Barrier translation factor : Value The preferred range is 0.01 to 0.1; sampling time The value range is the set of discrete moments of a uniform sampling time grid;

[0082] State coding for each device combination Several response segments were collected, and the reduction magnitude, temperature rise in key areas, and motion consumption (start / stop count, cumulative frequency change) were extracted from these segments. Based on this, two types of piecewise linear interpolation functions were established:

[0083] Temperature rise interpolation function Temperature rise function Input is the candidate reduction range. The output is the number of contracts maintained under this mode for the duration of the contract. Predicted temperature rise in key areas. Action consumption interpolation function. Action function. Input is the candidate reduction range. The output is the number of steps required to achieve the reduction in this mode. Consumption of similar actions.

[0084] Based on this, we can define:

[0085]

[0086] Temperature margin function : Range of values Its function is to characterize the magnitude of candidate reduction. Key Area Predictable margin for distance from upper limit. Upper limit of temperature in key areas. The value range is real numbers, and its function is to define the upper limit of comfort as specified in the contract. Measured temperature in key areas. The value range is a real number, and the source is the temperature sensor in the critical end area or the return air temperature sensor. Its function is to serve as the starting point for prediction.

[0087] Temperature rise function The value range is non-negative real numbers, and its function is to map the reduction magnitude to the predicted temperature rise. Equipment combination status coding. : Same function as before.

[0088] Motion margin can be defined as:

[0089]

[0090] Action margin function : Range of values Its function is to characterize the magnitude of candidate reduction. Next The remaining amount of the action budget. The upper limit of the action budget. The value range is positive real number or positive integer. Its function is to set the upper limit of the fixed action budget in the contract, such as the upper limit of the number of start-stop times or the upper limit of the cumulative change in frequency.

[0091] Action function The value range is non-negative real numbers, and its function is to map the reduction magnitude to the predicted amount of action consumption.

[0092] in and The specific form can be piecewise linear interpolation: for each pattern Several discrete points are obtained from the response fragment. and ,according to In ascending order; when When the value falls between two adjacent points, it is calculated by linear interpolation.

[0093] The edge controller preferably employs a one-dimensional search combined with feasibility assessment to solve the aforementioned maximization problem: first, a starting value is selected within the reduction range; then, the candidate reduction range is increased step by step, and two sets of barrier sums are calculated. If any barrier sum is lower than the corresponding budget threshold, the step size is reduced, and a binary search is performed within that range until convergence. The mapping table calculation window is consistent with the contract duration, ensuring the calculation of temperature and motion margins is closed. Subsequently, the deliverable reduction upper and lower bounds are written into the reduction envelope field, and the comfort risk budget and equipment motion budget are written into the contract field. The recovery constraint field separately describes the recovery period after the contract ends, preferably between fifteen and sixty minutes, and provides an upper limit for the allowable power recovery slope at each sampling time, enabling subsequent stages to control the recovery rate according to contract constraints.

[0094] In practice, the reduction envelope incorporates both temperature and motion margins into the constraints, ensuring the sustainability of the reduction upper limit given in the contract and compatibility with equipment protection. Risk budgeting and recovery constraints are fixed as contract fields, allowing subsequent verification and acceptance to be performed under the same criteria, reducing disputes caused by changes in caliber.

[0095] Step 2 is used to convert the deliverability contract into a commitment summary and obtain a reliable timestamp certificate for solidification without disclosing the original contract text, forming a correspondence between the contract number and the commitment index, so that the contract version can be recalculated and verified after the event and the caliber can be locked.

[0096] In demand response scenarios, disputes over contract terminology typically arise after the event has concluded: one type of dispute stems from changes in baseline terminology, while another arises from post-event adjustments to the envelope boundaries. If the original contract text is directly uploaded to the cloud and stored long-term before the event, it introduces the risk of sensitive operational data leakage and increases communication and storage burdens; if the original contract text is only stored at the edge and not permanently archived, the cloud will find it difficult to prove whether the original contract text has been replaced after the event.

[0097] Step two involves converting the deliverability contract into a repeatable, computable contract normalization string without revealing the original contract text. Then, a random salt value is introduced to generate a commitment digest. Then, the commitment summary is bound to the authoritative time as a trusted timestamp credential. Ultimately, a set of verifiable commitment indexes is formed on both the cloud and the edge, enabling subsequent out-of-bounds verification, downgrade execution, and acceptance settlement to revolve around the same commitment object without any shift in scope.

[0098] First, the deliverability contract from step one is transcribed into a contract canonical string, and then a commitment summary is generated based on this. The contract canonical string ensures that the same contract text is represented by a consistent byte sequence across different devices and operating cycles, while the commitment summary ensures that the contract is formed before the event and cannot be silently replaced subsequently.

[0099] If contract fields are not ordered correctly, have inconsistent numerical representations, or use mixed units during serialization, the same contract may yield different commitment summaries on different edge controllers, leading to new disputes regarding contract consistency after an event. To avoid such disputes, all fields of the deliverability contract are written into the contract normalization string in a fixed order, and a unified fixed-point representation rule is adopted for fields involving units and precision.

[0100] The edge controller first generates a list of contract fields locally. This list includes fields for the event window, unresponsive baseline power curve, deliverable reduction envelope, ramp capability, duration, comfort risk budget, equipment action budget, recovery constraint, model version, and validity period. The edge controller then assigns a unique identifier to each field and writes them into the contract normalized string in ascending order of identifier. The field identifiers and the writing order are locked by the edge controller firmware configuration and remain unchanged throughout the contract's validity period. The unresponsive baseline power curve field uses the sampling time as the reference time. For index writing, the sampling time set in step one is strictly followed during writing, without adding or deleting sampling points, to avoid the deviation of different sampling calibers of the same curve before and after the event.

[0101] The deliverable reduction envelope field is written with the same set of sampling times as the index, and the upper bound is written with the deliverable reduction upper bound. The lower bound is written into the deliverable reduction lower bound, and the two are stored adjacently in the contract normalization string so as to locate envelope differences during subsequent comparison.

[0102] Numerical fields are written using fixed-point scaling: the edge controller uses a fixed scaling factor for power fields, ensuring that power fields are represented by the same integer sequence across different programming languages ​​and floating-point implementations; temperature fields also use a fixed scaling factor, ensuring that the upper temperature limit and temperature margin in key areas have verifiable accuracy in the contract normalization string. Enumerated fields, such as time period type and model version fields, are written using explicit enumeration table encoding. The enumeration table is released with the firmware version and records the version number, preventing manual modification of enumeration values. Data quality scoring fields are also included. The edge controller does not write the score as a separate contract field into the envelope ontology. Instead, it writes the score threshold plus the score generation rule identifier to ensure that the contract commitment focuses on the deliverable boundary, and the score is used to explain the source of that boundary.

[0103] When used, a standardized contract string is generated using fixed field identifiers and a fixed writing order. Power and temperature fields are represented by fixed-point scaling, and the sampling time set maintains consistency in curve caliber. The power curve and envelope curve share the same sampling time set, and subsequent verification will locate out-of-bounds errors moment by moment without using interpolation assumptions. Scoring rules are written through identifiers, separating contract commitment boundaries from data interpretation caliber, and reducing sources of commitment object drift.

[0104] If the commitment summary is generated directly from the contract normalization string calculation, the commitment summary can be traversed offline by a third party to infer the contract content; the generation of random salt values ​​is uncontrollable or repetitive, which may lead to the risk of reusing the same commitment summary for different events. The one-time nature and confidentiality of random salt values ​​enable the commitment summary to be cloud-based without revealing the original contract text.

[0105] Before generating a random salt value, the edge controller reads a local monotonic counter. This monotonic counter only changes and is written to a secure storage area to prevent the sequence from repeating after a device restart. The edge controller reads the device fingerprint field, which is obtained by concatenating the device's unique hardware identifier and firmware version identifier. Then, the edge controller generates an initial seed using the device fingerprint field, the monotonic counter, and the current contract number as inputs. It reads a perturbation fragment from a secure random source and combines the initial seed and the perturbation fragment to generate a random salt value. The length of the random salt value is selected to be 16-32 bytes, which satisfies the combination space under the condition of controllable communication and storage overhead.

[0106] Among them, the edge controller introduces a hash function when calculating the commitment summary. The output bit length of the hash function is fixed, and it irreversibly compresses the input bit sequence. The hash function can be a commercial cryptographic hash algorithm or a publicly available standard hash algorithm. The algorithm identifier is written as an auxiliary field of the contract normalization string, and the same algorithm is used for post-verification.

[0107] The commitment summary is calculated according to the following formula:

[0108]

[0109] In the formula: Summary of commitment : Values ​​are fixed-length bit strings used as pre-contract event commitment fingerprints and uploaded to the cloud for timestamp binding; hash function The range of values ​​is a mapping from bit strings of arbitrary length to bit strings of fixed length, used to perform irreversible compression and collision resistance on contract normalized strings and random salt values;

[0110] Contract standardization : A normalized byte sequence for a deliverability contract; random salt value : A bit string of fixed length; concatenation operator The value is obtained by concatenating two bit strings, and is used to input the hash function by combining the normalized string and the random salt value.

[0111] Define contract normalization function Its input is a set of contract fields, and its output is a normalized contract string. :

[0112]

[0113] Contract normalization function The range of values ​​is the mapping from the field set to the byte sequence. Its function is to eliminate differences in field order, precision and unit, so that the contract can be recalculated.

[0114] Contract standardization The value range is a byte sequence, and its function is to commit to the digest input.

[0115] exist In the text, the numeric field uses a fixed-point scaling function. :

[0116]

[0117] Fixed-point scaling function : Values ​​are integers, used to convert real numbers A function that can reproduce integers. Scaling factor. : Values ​​are positive integers, derived from the system parameter table, used to fix precision and units; rounding function : Takes an integer value and is used to map a real number to an approximate integer.

[0118] The field encoding format uses a sequential concatenation of field identifier - field length - field content, with field identifiers arranged in ascending order; array fields (such as...) , The encoding method uses array length minus element-wise fixed-point scaling, and the sampling period is written in the encoding header. With the start sampling time This ensures consistency in post-event recalculations.

[0119] Hash function Either the national cryptographic hash algorithm or the publicly available standard hash algorithm can be used, with a fixed output bit length (e.g., (bits), the output is represented as a fixed-length byte sequence and participates in subsequent... The hash function algorithm identifier is written into the contract normalization configuration digest and carried with the disclosure package, enabling the recalculation in step four. It is possible to determine the implementation path of the same algorithm at that time.

[0120] In practice, a seed is generated using the device fingerprint field, a monotonic counter, and the contract number. A secure random source is then introduced to perturb the seed and generate a random salt value. A hash function is then used to calculate the commitment digest using the normalized contract string and the random salt value. The one-time nature of the random salt value reduces the risk of the commitment digest being reused, ensuring that the commitment digest corresponds to a unique contract version. The irreversibility of the hash function allows the cloud to solidify the commitment by only storing the commitment digest without accessing the original contract text, thereby reducing the path for sensitive operational data leakage.

[0121] Furthermore, the commitment summary and authoritative time are bound together as a trusted timestamp credential, and the index is sealed on both the cloud and edge. The trusted timestamp credential is used to prove that the commitment summary occurred before the event, and the dual-end sealing is used to prove that the binding relationship between the commitment summary, contract number, and timestamp credential has not changed.

[0122] If the cloud only receives the commitment digest without obtaining a trusted timestamp certificate, it cannot prove that the commitment digest was formed before the arrival of the demand response instruction. If the timestamp receipt lacks verification, attackers may forge receipts to replace the timestamp.

[0123] Upon receiving the commitment digest, the cloud generates a timestamp request message. This message includes fields for commitment digest, hash algorithm identifier, request sequence number, requester certificate identifier, and contract number. The request sequence number is generated by a cloud-based monotonic counter and written to the request log to prevent replay receipts. The cloud then sends the request message to a third-party trusted timestamp server. The trusted timestamp server returns a timestamp receipt, which includes the timestamp time, commitment digest display field, server signature field, and receipt sequence number field. Upon receiving the receipt, the cloud first verifies the server signature, then checks if the commitment digest display field in the receipt matches the local commitment digest, and finally verifies the correspondence between the receipt sequence number and the request sequence number. Once all three verifications pass, the cloud records the receipt as a trusted timestamp credential. .

[0124] To avoid blocking subsequent control and preparation of the timestamp link, the cloud sets a timeout window for timestamp requests, preferably between five and thirty seconds, and sets a fixed number of retries. If the retries still fail, the commitment digest is marked as pending completion and the edge controller is notified to enter the resend process.

[0125] To prevent mismatches between contract numbers and timestamp credentials, the cloud calculates the binding code before storage. The binding code links the contract number, commitment summary, and trusted timestamp credential into a single digest, which is then written to the cloud commitment index table. The binding code calculation formula is as follows:

[0126]

[0127] Binding code The value is a fixed-length bit string used as a verification digest for the cloud commitment index, and is used to detect substitutions or mismatches between the commitment digest and the trusted timestamp credential; commitment digest A fixed-length bit string used as a contract commitment fingerprint and participating in the generation of binding codes; a trusted timestamp credential. The value is a structured receipt bit string;

[0128] Hash function : Values ​​are mappings from arbitrary-length bit strings to fixed-length bit strings, used to perform irreversible compression and collision resistance on bound inputs; splicing operator The value range is the operation of concatenating two bit strings, used to input the hash function by combining the commitment digest and the trusted timestamp certificate;

[0129] A timestamp request message containing a request sequence number and contract number is constructed in the cloud. The receipt signature and echo fields are verified, a trusted timestamp certificate is generated, and the binding code is written to the commitment index table. The trusted timestamp certificate provides the time when the commitment summary was formed. Post-event verification is based on the authoritative time. The binding code binds the commitment summary to the trusted timestamp certificate to prevent mismatch of commitment objects in cloud storage.

[0130] Furthermore, if the edge side only saves the original contract text and not the random salt value used to generate the commitment summary, the commitment summary cannot be recalculated after the event; if the edge side's saving process can be overwritten, the contract may be replaced after the event but cannot be detected.

[0131] Immediately after generating the commitment summary, the edge controller writes the original contract text, random salt value, contract number, hash algorithm identifier, and contract normalized string version number to the sealed storage area, and assigns a write sequence number to this record. This write sequence number is associated with a monotonic counter to prevent rollback. The sealed storage area uses an append-only write method, disallowing in-situ overwriting of already written records. If the storage medium does not support append-only writes, the edge controller uses alternating dual-partition writes and identifies the currently valid partition with a partition header signature. The edge controller also stores a copy of the trusted timestamp certificate returned from the cloud or its receipt summary, allowing the edge to review the commitment index locally even when the network is down.

[0132] The edge controller prepares a disclosure package for disclosure verification. This package contains the original contract text, a random salt value, and a summary of the contract canonical string generation configuration. This allows the cloud to recalculate the contract canonical string according to the same field ordering and fixed-point scaling rules when verifying the commitment summary. The disclosure package is not sent before the event by default; it is only sent by the edge controller upon cloud request during the post-event acceptance phase or dispute review phase. If the edge controller experiences a power outage before the timestamp receipt arrives, it will scan the sealed storage area according to the write sequence number after restarting, find records for which commitment summaries have been generated but timestamp certificates have not been obtained, and resend the commitment summaries to the cloud to complete the timestamp binding. The original contract number is included during the resend to maintain index consistency.

[0133] When in use, the edge side saves the original text and random salt value by appending or alternating dual partitions, generates a normalized configuration summary disclosure package, and reissues the commitment summary and index scan in the event of power failure or network interruption. Sealed storage ensures that the original contract text and random salt value are consistent before and after the event, enabling the commitment summary to be recalculated after the event without the need for manual recording.

[0134] Step 3: Bind the demand response instruction to the contract number, complete the contract consistency verification and feasible domain verification based on the deliverability contract, generate an executable degradation curve beyond the boundary, execute adaptive closed-loop control according to the control arbitration mechanism and the point authority matrix, and upload the evidence summary chain and solidify it.

[0135] Demand response instructions are highly time-sensitive; once an instruction arrives, its feasibility must be determined and an executable action provided within a short timeframe. If the edge controller directly rewrites the outlet water temperature setting or the number of units based solely on the instruction target, it can easily trigger equipment protection and cause the comfort boundary to approach. If the cloud directly issues a fixed reduction value without verifying the contract envelope, it can easily lead to instruction exceeding the limit and execution failure. On the other hand, in real-world scenarios, building automation plans, energy-saving strategies, safety protections, and human operations often coexist. Without a verifiable arbitration link, it is difficult to explain why the instruction was not executed as requested or why the execution range was narrowed after an incident. Therefore, step three uses the commitment index as an anchor point to solidify and link the contract consistency verification, automatic degradation due to exceeding the limit, arbitration writing, rolling constraint control, and evidence summary chain into a single chain. This ensures that each writing action has a pre-boundary and post-evidence, allowing the acceptance and settlement in step four to be traceable back to the same standard. First, the demand response instruction issued by the cloud is used as input. The commitment index is retrieved by the contract number and consistency verification is completed. Then, based on the deliverable reduction envelope, the instruction target is determined at each moment to see if it exceeds the limit, and an executable degradation curve is generated when it does.

[0136] When a demand response command enters the edge controller from the cloud platform, if the reliability of the communication link is used as the sole basis for trust, issues such as command replay, mismatched contract numbers, and inconsistencies between the command window and the contract window may still occur.

[0137] First, the instructions are written into a parsable instruction package. Then, the instruction package is checked against the commitment index formed in step two item by item, so that the edge controller can eliminate the potential problem of inconsistency between the instruction source and the contract source before entering the envelope determination.

[0138] The cloud sends instruction packets to the edge controller. These packets include at least the contract number, instruction sequence number, event window, target reduction curve, ramp requirement, priority, and integrity verification fields. Upon receiving the packet, the edge controller first verifies the integrity verification field. This field can optionally use a Cyclic Redundancy Check (CRC) code or a message authentication code. A CRC code is used to quickly detect transmission errors, while a message authentication code is used to detect content tampering.

[0139] After the integrity verification passes, the edge controller retrieves the locally cached commitment digest using the contract number. With trusted timestamp credentials And obtain the binding code from the commitment index returned from the cloud. The edge controller recalculates the binding code locally according to the binding code calculation rules agreed upon in step two and compares it with the code. It then checks whether the echoed fields of the trusted timestamp certificate match the commitment summary. Finally, it checks whether the instruction window falls within the contract validity period field and the contract event window field. If any of the above checks fails, the edge controller marks the instruction packet as unexecutable and generates a rejection receipt. The rejection receipt contains the rejection reason code and the name of the rejected field, thus explaining after the event that the rejection was due to a contract index inconsistency rather than a controller failure.

[0140] During use, the edge controller first performs integrity checks, commitment index comparisons, and consistency checks between the event window and the contract window, generating field-level reason code rejection receipts. The structured instruction packets facilitate individual verification by the edge controller, avoiding the need to judge instruction trustworthiness based on communication status. The commitment index verification... , , Linked to contract number to prevent out-of-bounds execution due to contract mismatch. Rejection receipts contain field-level reason codes, tracing back to contractual or instruction definitions, rather than verbal explanations.

[0141] After confirming that the instruction and contract are consistent, it is still necessary to determine whether the instruction target is reachable within the contract envelope. If the boundary crossing handling is written as simply taking the minimum value, abrupt changes will occur near the envelope boundary, causing jumps in the pump frequency and outlet water temperature settings; if no boundary crossing handling is performed and the instruction is executed directly, comfort constraints or equipment protection will be triggered.

[0142] Therefore, the edge controller reads the sampling time from the contract. The corresponding deliverable reduction upper and lower bounds are defined, and the target reduction value corresponding to the same sampling time is read from the instruction packet. The edge controller first performs time-by-time boundary judgment: when the target reduction value is greater than the deliverable reduction upper bound, it is judged as an upper boundary violation; when the target reduction value is less than the deliverable reduction lower bound, it is judged as a lower boundary violation. To avoid step jumps at the boundary points, the edge controller extends a transition window at the beginning and end of the boundary segment. The length of the transition window is calculated from the ramp requirement field, so that the degradation curve gradually approaches the envelope boundary with a monotonically increasing slope within the transition window. When generating the degradation curve, the remaining amount markers of the comfort risk budget and the equipment action budget are checked simultaneously. If the remaining amount markers are in a tightening state, the upper limit of the slope of the degradation curve is further converged within the same transition window, so that the control actions do not occur in a concentrated manner in a short period of time. If there are multiple discrete peak points in the instruction target, the edge controller prioritizes smoothing the peak points during degradation, and then performs envelope pruning on the smoothed curve, thereby avoiding frequent starts and stops caused by peaks.

[0143] In use, the edge controller performs out-of-bounds determination based on the deliverable reduction envelope, generates continuous executable degradation curves according to ramping requirements, and writes the out-of-bounds type and degradation reason into the degradation reason field. Out-of-bounds determination is aligned with the contract sampling time set on a time-by-time basis, allowing direct comparison of the degradation curve and contract boundary on the time grid, avoiding interpolation discrepancies. Transition windows and slope convergence ensure the continuity of the degradation curve, reducing the probability of equipment protection triggering due to control variable jumps.

[0144] Using the executable degradation curve as input, the system arbitrates and writes writable points under the condition of multiple source controls coexisting on-site. It then generates a specific control quantity sequence using rolling constraint control, and simultaneously forms an evidence summary chain of the execution process and key states, which is then uploaded to the cloud for solidification. Central air conditioning systems typically involve both building automation plans and manual operations on-site. If demand response execution directly covers all points, it will disrupt existing protection logic and introduce the risk of misoperation.

[0145] Therefore, the controllable quantity of demand response is limited by the set of writable points, and the priority of security protection, comfort hard constraints, demand response, and routine planning is fixed by arbitration timing, so that each write has a clear source path.

[0146] Before an event begins, the edge controller loads a point permission matrix. This matrix, indexed by point identifiers, assigns four types of constraints to each point: the set of allowed write sources, the maximum write frequency, the minimum hold time, and the allowed range of change. The set of allowed write sources clearly distinguishes between security protection sources, building automation plan sources, manual operation sources, and demand response sources. After an event begins, the edge controller reads the locking flag of the security protection source in each sampling period. If the locking flag is locked, the point is marked as unwritable in that period, and the reason is written to the arbitration record. If it is not locked, the edge controller reads the boundary crossing flag of the comfort hard constraint. This boundary crossing flag is derived from the comparison between the critical area temperature and the contract temperature upper limit. If the boundary crossing flag is triggered, the write range of the demand response source to that point is tightened to the lower limit of the allowed range of change given by the point permission matrix, and the tightening reason is written to the arbitration record. If it is not out of bounds, a set of writable point combinations is selected for writing, driven by the current reduction target of the executable degradation curve. The selection of sampling points follows a sequence from low-risk to high-risk points. Low-risk points are those that are continuously adjustable and do not cause start-up or shutdown, including fine-tuning of outlet water temperature settings, pump frequency upper limit, and tower fan frequency. High-risk points are those that may cause start-up, shutdown, or operation mode switching, including switching the number of chillers and switching pump start-up / shutdown. Before writing to high-risk points, the edge controller checks the minimum hold time and maximum write frequency of the sampling point permission matrix. If these conditions are not met, the delay is postponed to the next sampling period, and the reason for the delay is written into the arbitration record.

[0147] In use, the edge controller determines the write source according to a preset arbitration sequence and uses a point permission matrix to limit writable points, write frequency, minimum hold time, and allowed variation range. Simultaneously, the trigger flag and reason for each arbitration are written to the arbitration record. The point permission matrix realistically defines the reachable range of the demand response, reducing the cascading risks caused by coverage protection logic.

[0148] Fixed arbitration timing ensures that arbitration results are reproducible under the same operating conditions, facilitating post-event review. The strategy of prioritizing low-risk points and delaying the writing of high-risk points makes reduction targets more likely to be achieved through continuously adjustable points, reducing the possibility of concentrated start-up and shutdown actions.

[0149] After arbitration, specific control quantities still need to be generated to ensure that the actual power varies along the executable degradation curve while maintaining comfort and equipment protection constraints. Using the executable degradation curve as the target input and the non-responding baseline power curve and data quality score as the verification criteria, the control quantities are solved at fixed intervals and sent to the building automation controller or frequency converter. Then, execution receipts and key states are collected to form an evidence summary chain, which is uploaded to the cloud for permanent storage.

[0150] In this process, the edge controller constructs a current state snapshot in each sampling period. This snapshot includes measured power, critical area temperature, equipment combination status, previously written point values, and arbitration record indexes. The edge controller uses the state snapshot and the current-moment objective of the executable degradation curve to formulate a problem. The decision variables for solving this problem are the point increments allowed to be written by the point permission matrix. Constraints are derived from the allowable change range, minimum hold time, and maximum write frequency of the point permission matrix, as well as the tightening flags of the contract's comfort risk budget and equipment action budget. The solution method can be either a quadratic programming solver or a linear programming solver. Quadratic programming incorporates both power deviation and point change range into the cost function, while linear programming incorporates the combination selection of discretized point increments into the constraints. After solving, the edge controller issues write commands according to the point writing order, carrying the instruction sequence number and point writing sequence number in the command, ensuring that the building automation controller's acknowledgments correspond to specific write actions. After collecting the acknowledgments, the edge controller writes success, rejection, and timeout to the execution record and links the rejection reason to the arbitration record.

[0151] As a supplement: Let the writable point increment be the point increment. The power sensitivity coefficient is the sensitivity coefficient. Then it can be used:

[0152]

[0153] Predicted power prediction The range of values ​​is Its function is to serve as the predictive output for rolling constraint control; measured power : Function as before; Number of actions The value range is positive integers, and its function is to enumerate the number of writable points or control actions;

[0154] Sensitivity coefficient : The value range is real numbers, and its function is to represent the pattern Next The impact of a single point increment on power can be obtained through response segment regression or piecewise interpolation; point increment The range of values ​​is given by the point access matrix, and its function is to be the decision variable in the rolling solution.

[0155] To ensure process verifiability, the edge controller concatenates the execution record, arbitration record, and key state snapshots from each sampling period into a process record string. The process record string is linked line by line using a hash function to form the end-of-chain summary of the evidence summary chain. :

[0156]

[0157] Where: End summary of the evidence summary chain The value is a fixed-length bit string used to represent a summary of the process record chain up to the sampling time and is used to upload it to the cloud for storage;

[0158] Previous Summary : Values ​​are fixed-length bit strings used to form a chained digest with the current process record string, so that any change in any record will change the subsequent digests; initialization uses anchored commitment digests:

[0159]

[0160] Evidence summary chain start summary : Values ​​are fixed-length bit strings, used as the starting point of a chained digest one clock cycle before the event begins; commitment digest : Same function as before; Event starting point index The value range is positive integer, and its function is to represent the index corresponding to the starting sampling time of the event window.

[0161] Process record string The value is a variable-length bit string used to carry the measured power at the sampling time. , Standardized representation of instruction sequence number, arbitration record, write point value, receipt status, and alarm flag; and The same standardization rule of field identifier + fixed order + fixed-point scaling is adopted, and the fields must include at least: sampling time, contract number, instruction sequence number, and measured power. Unresponsive baseline power curve value Deliverable reduction upper bound Out-of-boundary downgrade flag, arbitration flag, point write value, receipt status, alarm flag.

[0162] Hash function The value range is the mapping from bit strings of arbitrary length to bit strings of fixed length; sampling time The value range is the set of discrete moments of the unified sampling time grid agreed upon in step one;

[0163] In terms of data upload and solidification, the edge controller uploads the end-of-chain summary of the evidence summary chain to the cloud at fixed intervals. The fixed interval is preferably one to five sampling periods to keep the upload frequency and communication load balanced. After receiving the end-of-chain summary of the evidence summary chain, the cloud obtains a trusted timestamp certificate and archives it according to the same trusted timestamp process in step two, so that step four can verify whether the process record at a certain moment has been rewritten during dispute review.

[0164] The edge controller constructs a rolling control solution problem based on state snapshots and the executable degradation curve. The solved point increments are written in a preset order, while simultaneously collecting receipts to form a process record string and generating a chained summary, which is then uploaded to the cloud for timestamped archiving. The rolling constraint control incorporates envelope boundaries, point permission matrices, and risk budget tightening markers into the solution, ensuring that the generated control variables are consistent with contract boundaries. Receipt collection is linked to arbitration records, enabling the identification of rejection or protection lock reasons for non-execution. Evaluation metrics can include the number of instruction out-of-bounds occurrences, the number of arbitration triggers, the summary chain verification pass status, and the type of receipt rejection reason.

[0165] Step 4: After the event ends, the edge controller displays the original deliverability contract and a random salt value. The cloud platform recalculates and compares the commitment summary and prints a trusted timestamp certificate. It then combines the evidence summary chain to accept and settle the transaction and prints out the settlement evidence package. Finally, it updates the model version based on the execution deviation for reference in the next contract.

[0166] In the implementation of demand response services, whether on-site execution meets standards is often not simply a matter of power degradation, but rather whether the commitment targets are consistent, the execution process is traceable, and the acceptance criteria are recalculated. If only the power curve is uploaded after an event without the commitment index, the cloud cannot prove whether the non-responding baseline power curve is the version committed before the event. If full operational data is required from the edge for verification after an event, it introduces the risk of data volume and sensitive data leakage. On the other hand, if on-site rejection receipts, arbitration records, and alarm flags are not included in the acceptance process, settlement disputes will revert to verbal explanations. Therefore, step four uses a commitment summary. The end of the evidence summary chain serves as a dual anchor point. First, the disclosure verification and summary chain consistency verification are completed. Then, within the same sampling time set, the acceptance report and settlement evidence package are generated. Subsequently, the acceptance results are transcribed into model version update instructions, enabling subsequent steps to reuse the updated parameter window without changing the terminology mapping.

[0167] Specifically, using the edge-side disclosure package as input and the cloud commitment index and cloud summary solidified index as references, the disclosure verification of the original contract text and random salt value is completed, and the consistency verification of selectively disclosed evidence is completed within the dispute window.

[0168] The key to revealing the verification process lies in the fact that the cloud-based system does not rely on verbal explanations from the edge, but rather on repeatable digest comparisons to confirm the contract version. If the representation of contract fields changes before and after an event, it will lead to inconsistent recalculation results for the same contract, causing revealing verification to fail. This follows the contract normalization string from step two. The rules involve recalculating the standardized contract commitment summary in the cloud, comparing it with the commitment summary stored in the cloud, verifying the echo field of the trusted timestamp certificate, and finally forming a contract version confirmation result.

[0169] The cloud sends a disclosure request to the edge controller, which includes the contract number, request sequence number, and expected hash algorithm identifier, and sets the response time to five to thirty minutes. The edge controller then stores the original contract text and a random salt value from the sealed storage area. The standardized configuration summary of the contract is then packaged together into a disclosure package.

[0170] After the disclosure packet arrives at the cloud, the cloud first verifies the integrity verification field of the disclosure packet, and then recalculates the contract normalization string according to the contract normalization configuration summary. Next, the hash function, consistent with step two, is used to recalculate the commitment digest and compare it with the cloud commitment digest. The recalculation formula is as follows:

[0171]

[0172] In the formula: Summary of commitment : Values ​​are fixed-length bit strings used as contract commitment fingerprints and for comparison with cloud indexes; hash function : Values ​​are mappings from arbitrary-length bit strings to fixed-length bit strings, used for irreversible compression and collision resistance of contractually normalized strings and random salt values; contractually normalized strings The value is a normalized byte sequence generated by field-ordering and fixed-point scaling of the original contract text. It is used to eliminate serialization differences and carry the commitment content, including the non-response baseline power curve and the upper bound of deliverable reduction.

[0173] random salt value A fixed-length bit string with values ​​ranging from 1 to 2, used to break down the predictability of commitment digests and avoid commitment digests of the same contract; concatenation operator. The value range is the input of the hash function formed by concatenating two bit strings; the algorithm identifier of the hash function reveals the identifier carried by the packet, and is implemented uniformly in the cloud.

[0174] After the comparison is consistent, the cloud further verifies the server signature of the trusted timestamp certificate and verifies that the echo field of the trusted timestamp certificate is consistent with the commitment digest stored in the cloud. Then it verifies that the timestamp time of the trusted timestamp certificate is earlier than the arrival time of the demand response instruction.

[0175] If an inconsistency occurs, the cloud will display the verification status as failed and freeze the automatic settlement entry for this event. At the same time, it will output the difference location information, which includes one of the following four types of reason codes: missing contract fields, inconsistent field order, inconsistent fixed-point scaling factors, and mismatched random salt values. The reason code will be written to the audit log.

[0176] When used, the cloud recalculates the contract normalization string using the contract normalization configuration summary. Then, the commitment summary is recalculated using a hash function and a random salt value. The system verifies the signature, echo fields, and time sequence of the trusted timestamp credential, and finally writes it to the audit log. The disclosure package only exposes the original contract text and a random salt value, without requiring the submission of all runtime data, thus decoupling version confirmation from runtime data disclosure. Trusted timestamp credential verification binds the commitment summary to the authoritative time, ensuring that contract confirmation relies not only on content consistency but also on the traceability of its creation time.

[0177] Furthermore, even after the contract version is finalized, disputes may still arise regarding the authenticity of the execution process and the authenticity of key receipts. Judging solely from the final power curve would overlook the arbitration record and reasons for refusal in step three, thus eliminating the potential for dispute. Using the end-of-chain summary of evidence fixed in the cloud as the external anchor point, and the process record strings available on the edge side as internal evidence, selective disclosure ensures complete data consistency verification.

[0178] In this process, after the event ends, the cloud first reads the summary sequence index of the event from the summary solidification index table. The summary sequence index is based on the sampling time. Record the end-of-chain summary of each submitted evidence summary and its corresponding timestamp receipt number. The cloud verifies the server-side signature of the timestamp receipt and checks that the displayed field matches the summary value, establishing the credibility of the summary's solidified trajectory. Based on this, the cloud extracts the dispute window according to the acceptance rules. The extraction of the dispute window is not solely based on the absolute value of the power deviation, but rather on three types of triggering conditions: instruction out-of-bounds degradation flag trigger, control arbitration trigger, and security protection lock trigger. All of the above triggering conditions originate from the arbitration record and degradation reason field written in step three. The cloud can locate the set of trigger sampling times by reading the event-level index list sent from the edge side.

[0179] Once the disputed window is determined, the cloud sends a disclosure request to the edge, which includes the set of sampling times for the disputed window and the set of fields to be disclosed. The edge then exports only the process record string corresponding to that window upon request. The process record string normalization rules from step three are continued during export to ensure consistency of the same field across different disclosure batches. Upon receiving the disclosure fragment, the cloud recalculates the chained summary for each process record string and verifies whether the final summary of the derived evidence summary chain matches the corresponding sampling time summary fixed in the cloud. If they match, the disclosure fragment is determined to be consistent with the fixed summary; otherwise, it is determined to be inconsistent, and the inconsistent sampling time is written into the review queue.

[0180] In use, the cloud first verifies the timestamp receipts of the end-of-chain evidence summary one by one. Then, it extracts the dispute window based on three conditions: downgrade flag, arbitration trigger, and security protection lock. Finally, it requests the process record string from the edge side according to the window. The consistency between the disclosed segments and the fixed summaries is verified by chain-based summary recalculation.

[0181] Ultimately, the credibility of the summary trajectory is established by the timestamp receipt of the summary at the end of the evidence summary chain, ensuring that subsequent verification does not rely on unilateral statements from peripheral parties. The dispute window is located by triggering conditions, avoiding the requirement to disclose the entire record and limiting the scope of data disclosure to necessary fragments.

[0182] Furthermore, after the contract version is confirmed and the process consistency verification is passed, the process proceeds to acceptance and settlement output, and the acceptance results are transcribed into model version update instructions, which are then written back to the baseline and envelope generation stage in step one.

[0183] Acceptance settlement must be consistent with the contract terms, especially the non-response baseline power curve and the upper limit of deliverable reduction must be derived from the confirmed contract version; otherwise, the response quantity calculation will lack a basis. After contract confirmation, the actual reduction is calculated using the same sampling time set, and acceptance elements are generated. Simultaneously, the commitment index, summary solidification trajectory, and necessary disclosure fragments are packaged into a settlement evidence package to make the settlement results verifiable. Specifically, the actual reduction is calculated as follows:

[0184]

[0185] Actual reduction The value range is real numbers, and its function is to represent the sampling time. The actual reduction amount is used as the basis for acceptance calculations; non-response baseline power curve Measured power : Same function as before;

[0186] Specifically, the cloud reads and reveals the verified contract content, locks the event window and sampling time set, and reads the measured power within that window. The measured power is preferably sampled from event-marked data from the main energy meter or individual energy meters. Event markers are written to the metering gateway by the edge controller at the start of step three, ensuring that event-period data is distinguishable from normal data. The cloud calculates the actual power reduction at each sampling moment. The actual power reduction is obtained by subtracting the measured power from the non-responding baseline power curve. Low-quality sampling points are included in the verification queue based on data quality scores and are not directly used for settlement master values. Simultaneously, the cloud generates comfort boundary violation statistics and recovery constraint verification results. Comfort boundary violation statistics are derived from the temperature trace field in key areas, and recovery constraint verification is derived from a comparison between the contract recovery constraint field and the power recovery trajectory after the event.

[0187] To make the acceptance conclusions auditable, the cloud writes each type of acceptance element as a structured field and provides the corresponding evidence source index number in the acceptance report. The source index number can point to the commitment index entry, the summary solidification index entry, or the disclosure fragment entry.

[0188] The encapsulation of the settlement evidence package follows the order of index priority, followed by fragment priority. The cloud first writes the commitment index triple: commitment summary. Trusted timestamp certificate Binding code Next, write the summary solidification trajectory index: the summary at the end of the evidence summary chain and the corresponding timestamp receipt number; then write the acceptance report field; finally, write the disclosure fragment. The disclosure fragment is only written when the dispute window exists or the data quality score is lower than the threshold. The disclosure fragment adopts field-level desensitization rules. The desensitization rules specify which fields retain their original values ​​and which fields are represented by range codes. The range code table is given a version number in the contract standardization configuration.

[0189] Define the interval boundary sequence for the interval encoding table. (Incrementing), for numeric fields Using interval coding function :

[0190]

[0191] Interval coding function : Takes a non-negative integer value, used to map the original numerical value to a field-level desensitization under the interval number. Interval boundary The value range is a real number, which comes from the project configuration or contract normalization configuration summary boundary table. Its function is to define the desensitization granularity.

[0192] When in use, the cloud calculates the actual reduction amount based on the contract sampling time set and manages the queue that needs to be reviewed in conjunction with the data quality score. At the same time, it encapsulates the commitment index, summary solidified trajectory index, acceptance report fields and necessary disclosure fragments to form a settlement evidence package, and writes the evidence source index number to each acceptance element.

[0193] Acceptance criteria are locked onto confirmed contract versions, ensuring traceability and recalculation of data sources. An index-prioritized evidence package structure allows for verification in most scenarios using only the index, reducing the size of disclosed fragments and the scope of sensitive exposure. Data quality scoring participates in acceptance queue management, preventing low-quality sampling points from directly altering the settlement master value.

[0194] After acceptance testing, the deviation mechanism obtained after the event still needs to be written back to step one; otherwise, the next event may still trigger degradation and arbitration repeatedly under the same operating conditions. The deviation types and triggering conditions in the acceptance report are transcribed into model update instructions, and the parameters before and after the update are sealed in a version chain manner, allowing the update to be rolled back without disrupting the terminology mapping.

[0195] The cloud reads three pieces of information from the acceptance report: the first is the distribution of out-of-bounds types, which originate from the degradation reason field in step three; the second is arbitration triggers, which originate from the arbitration records in step three; and the third is data quality anomalies, which originate from the rule identifiers generated by the data quality score in step one and the alarm markers in step three. The cloud maps this information to an update process. If out-of-bounds types are concentrated under the same device combination state code, the cloud generates an envelope write-back instruction, requiring the edge controller to thicken the risk budget tightening mark on the mapping table fragment of that device combination state when generating the next contract, so that the deliverable reduction upper bound converges earlier in this mode. If arbitration triggers are concentrated on writable points, the cloud generates a point permission matrix revision instruction, changing the allowed change range or minimum retention time of that point, so that the demand response write is more in line with device protection. If data quality anomalies are concentrated on the acquisition channel, the cloud generates an acquisition channel governance instruction, requiring the edge controller to add a consistency breach cost weight to that channel in the time alignment and missing repair in step one, so that the data quality score reflects the instability of that channel more quickly.

[0196] The cloud generates a model version number for each update action and writes the update action to the version chain log. The version chain log includes the old version number, the new version number, an update action summary, a trigger evidence index number, and a rollback condition field. The rollback condition field specifies under what circumstances to roll back to the old version. Rollback trigger conditions can be multiple consecutive events with the same type of rejection receipt or frequent triggering of critical area temperature out-of-bounds flags. The cloud distributes the version chain log to the edge controller. The edge controller reads the latest version number and loads the update action the next time it generates a contract in step one. To avoid conflicts between the update action and the contract commitment, the edge controller must generate a new contract number and re-execute step two, commitment solidification, after applying the update action; the old contract number is not overwritten.

[0197] In use, the cloud generates model version update actions based on event execution records and data quality records, archives the parameters before and after the update, and sends them to the edge controller, so that the update actions are loaded and take effect when the next deliverable capability contract is generated. The update actions use trigger conditions as entry points, making the adjustment of envelope convergence, point permission matrix, and data quality score weights traceable and not relying on experience guesswork. Version chain archiving allows model updates to be rolled back, avoiding long-term caliber drift caused by a single abnormal event.

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

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

[0200] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0201] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

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

Claims

1. A method for adaptive load control of central air conditioning systems based on edge-cloud collaboration, characterized in that: include, The edge controller collects and verifies data, generates a non-responding baseline power curve, calculates the deliverable reduction envelope based on device protection constraints and comfort constraints, and forms a deliverable capacity contract containing risk budget and recovery constraints. The edge controller calculates a commitment summary for the deliverable capacity contract and random salt value and reports it. The cloud platform obtains a trusted timestamp certificate for the commitment summary. The cloud platform issues demand response instructions associated with the deliverability contract. The edge controller performs feasible domain verification. When the boundary is exceeded, an executable degradation curve is generated. Control is implemented according to the control arbitration mechanism and the point authority matrix, and an evidence summary chain is generated. After the event, the edge controller reveals the deliverability contract and random salt value. The cloud platform recalculates and compares the commitment summary and verifies the trusted timestamp certificate. Based on the non-response baseline power curve and the evidence summary chain, a settlement evidence package is generated, and the deliverability reduction envelope is updated based on the execution deviation. The edge controller collects total power consumption, chilled water supply and return water temperature and flow rate, terminal key area temperature, outdoor weather conditions and time period type at a preset time before the demand response event begins. It performs time sequence alignment, missing data completion, anomaly removal and generates data quality score, and writes the data quality score, event window, model version and validity period into the deliverability contract. The unresponsive baseline power curve is obtained by the edge controller by weighting and aggregating the historical total power consumption based on the set of sampling times. The weighting coefficient is determined by the data quality score, outdoor weather conditions and equipment combination status coding. The generated unresponsive baseline power curve is written into the deliverability contract. The edge controller sets up a control arbitration mechanism and a point permission matrix to limit the control quantities that can be written in the demand response, as well as their change range and holding time. When conflicts arise with safety protection, comfort hard constraints, energy-saving strategies, or manual programming, arbitration shall be conducted in the following order: safety protection takes precedence, comfort hard constraints take precedence, and demand response takes precedence over conventional planning. The arbitration result and cause shall be written into the process record corresponding to the evidence summary chain.

2. The central air conditioning load adaptive control method according to claim 1, characterized in that: The equipment combination status code is obtained by concatenating the number of operating chiller units, the operating status of chilled pumps, the operating status of cooling pumps, and the operating status of cooling towers according to preset weights. The operating status includes start / stop status and frequency converter gear. The preset weights and gear division rules are written into the model version, and the equipment combination status code is associated with and saved with the sampling time set.

3. The central air conditioning load adaptive control method according to claim 2, characterized in that: The edge controller calculates the upper and lower bounds of the deliverable reduction envelope based on equipment protection constraints, operating condition constraints and comfort constraints in each time slice, and writes ramp capability and duration as time coupling parameters into the deliverable capability contract, where comfort constraints include the upper limit of temperature in critical areas.

4. The central air conditioning load adaptive control method according to claim 3, characterized in that: The risk budget includes a comfort risk budget and an equipment operation budget. The comfort risk budget includes the allowable temperature drift range and out-of-bounds tolerance, while the equipment operation budget includes the number of start-stop cycles and the cumulative frequency fluctuations. The recovery constraints include recovery slope limits and recovery peak limits, and are written into the deliverability contract.

5. The central air conditioning load adaptive control method according to claim 4, characterized in that: The edge controller generates a normalized contract string from the deliverability contract according to field identifiers, fixed order and fixed point representation, generates a random salt value, calculates a commitment summary from the normalized contract string and the random salt value and reports it to the cloud platform, and securely saves the original deliverability contract and random salt value locally.

6. The central air conditioning load adaptive control method according to claim 5, characterized in that: The random salt value is 16 to 32 bytes long. After receiving the commitment digest, the cloud platform applies for a trusted timestamp certificate from a third-party trusted timestamp service. The trusted timestamp certificate contains the issuance time and the issuer's signature. The commitment digest and the trusted timestamp certificate are associated to generate a binding code, which is stored in the commitment index and corresponds to the contract number.

7. The central air conditioning load adaptive control method according to claim 6, characterized in that: The demand response instruction includes the target reduction curve, effective time window, ramp-up requirements, priority, and instruction integrity verification information. The edge controller verifies the validity of the deliverable capability contract referenced by the demand response instruction and performs feasible domain verification. If the deliverable reduction envelope is exceeded, an executable degradation curve that meets the envelope boundary and ramp-up requirements is generated and the reason for the out-of-bounds error is returned.

8. The central air conditioning load adaptive control method according to claim 7, characterized in that: The edge controller performs rolling constraint control within a fixed control cycle. The rolling constraint control targets the power tracking deviation and writes comfort constraints, equipment protection constraints, and recovery constraints into the constraint conditions. It achieves an executable degradation curve by updating the chilled water outlet temperature setting, pump frequency range, cooling tower fan adjustment, and non-critical area setting values.

9. The central air conditioning load adaptive control method according to claim 8, characterized in that: The process log includes measured power, corresponding values ​​of the non-responding baseline power curve, corresponding values ​​of the target reduction curve, actual control quantities, key status quantities, alarm information, arbitration flags, and degradation flags; the edge controller links the process logs one by one according to the sampling period to generate an evidence summary chain, and sends the latest summary of the evidence summary chain to the cloud platform every one to five sampling periods to obtain a reliable timestamp for solidification.

10. The central air conditioning load adaptive control method according to claim 9, characterized in that: The edge controller reveals the original deliverability contract and random salt value to the cloud platform. The cloud platform recalculates and compares the commitment summary and verifies the trusted timestamp certificate to generate a settlement evidence package. During dispute review, the cloud platform selectively discloses process records according to the dispute time window and provides evidence summary chain verification path, while the edge controller updates the model version based on execution deviation.

Images