Distributed energy management intelligent regulation system based on source network load storage integration

Abstract

The application relates to the technical field of intelligent regulation and control of energy management, and discloses a distributed energy management intelligent regulation and control system based on source, network, load and storage integration. The system comprises a demand collection module which integrates to-be-allocated resource categories, a priority sorting module which dynamically generates a resource priority sequence by using real-time monitoring data of each link of source, network, load, storage and use, a resource demand analysis module which analyzes demand satisfaction and determines the required resource instance quantity according to the sequence, a resource adjustment module which, when energy is insufficient, withdraws the allocated low-priority instances to guarantee high-priority demand and realizes dynamic reallocation of resources, and a dispatch confirmation module which ensures the optimal allocation result. The application realizes dynamic evaluation of resource priority and adaptive adjustment of resources, and improves the accuracy of energy allocation, system resilience and overall utilization efficiency.

Description

Technical Field

[0001] This invention relates to the field of intelligent energy management and control technology, specifically to an intelligent control system for distributed energy management based on the integration of energy source, grid, load, storage, and utilization. Background Technology

[0002] Currently, the management and control of distributed energy systems largely rely on pre-set fixed rules or static priority strategies. These strategies are usually formulated during the system design phase based on historical data or anticipated scenarios, lacking the ability to perceive and respond to the real-time operating status of the system.

[0003] Existing technical solutions have shortcomings. Static allocation mechanisms exhibit rigidity and insufficient adaptability when faced with the randomness and volatility of both the energy source and load sides. When sudden high-priority energy demands occur, or when the total available energy decreases sharply due to weather conditions, the system struggles to quickly reconfigure limited resources, potentially leading to untimely fulfillment of critical loads or energy misallocation and waste. Once the resource allocation process is complete, it becomes relatively fixed, lacking a closed-loop, continuous optimization mechanism, and unable to ensure the satisfaction of higher-value demands by adjusting already allocated low-value tasks when resources are scarce.

[0004] Existing systems struggle to achieve coordinated optimization of resource allocation strategies and real-time system status. When resources are insufficient, the conventional approach is to reject new requests or place them in a waiting queue, which reduces the overall efficiency and reliability of the system. There is an urgent need for a control mechanism capable of dynamically assessing the importance of demand based on real-time data and possessing resource reallocation capabilities to enhance the resilience and economic efficiency of complex distributed energy systems. Summary of the Invention

[0005] The purpose of this invention is to provide an intelligent control system for distributed energy management based on the integration of source, grid, load, storage and utilization, so as to solve the problems mentioned in the background art.

[0006] To achieve the above objectives, the present invention provides an intelligent control system for distributed energy management based on the integration of source, grid, load, storage, and utilization, the system comprising:

[0007] The demand aggregation module accesses the energy demand database to obtain the resource categories associated with the current energy demand to be processed, and at the same time queries the resource status database to obtain the currently allocated resource categories. It then merges the resource categories associated with the energy demand to be processed with the allocated resource categories to generate a set of resource categories to be allocated.

[0008] The priority ranking module continuously receives real-time monitoring data from each link of the source, grid, load, storage and utilization, and uses the real-time monitoring data to evaluate the importance of each resource category in the set of resource categories to be allocated, and generates a resource priority sequence.

[0009] The resource demand analysis module selects resource categories one by one according to the order of resource priority sequence, analyzes whether the energy demand to be processed corresponding to the resource category can be met within the specified time interval. If it can be met, it is marked as a single resource instance allocation. If it cannot be met, it is determined that multiple resource instances are needed, and the number of required instances is estimated.

[0010] The resource adjustment module checks whether the total available energy is sufficient based on the number of required resource instances. If sufficient, it allocates a resource instance. If insufficient, it scans for instances of lower importance than the current resource category among the currently allocated resource categories. If such instances exist, it cancels their allocation and rechecks the total available energy. If none exist, it interrupts the current scheduling operation.

[0011] The scheduling confirmation module checks whether all allocated resource categories are at the top of the resource priority sequence. If so, the scheduling process is terminated; otherwise, the process is fed back to the resource demand analysis module to continue processing subsequent resource categories in the sequence until the entire sequence has been checked.

[0012] Preferably, when the priority ranking module performs importance assessment, it performs the following processing:

[0013] For each resource category, extract its share of energy consumption in global consumption, supply efficiency in global efficiency, actual transmission rate in global rate, unresponsive demand in global demand, and demand latency in global duration.

[0014] Using predefined impact factors, each share is aggregated and calculated to obtain the priority value for each resource category;

[0015] Based on the priority values, the resource categories are arranged in descending order to form a resource priority sequence.

[0016] Preferably, when analyzing whether the energy demand to be processed can be met within a specified time interval, the resource demand analysis module performs the following steps:

[0017] Calculate the amount of energy demand that the current resource category can handle within a specified time interval. This amount is obtained by multiplying the processing capacity of the resource category by the specified time interval.

[0018] Compare the amount of energy demand that can be processed with the total amount of energy demand to be processed;

[0019] If the amount of energy demand that can be handled is greater than or equal to the total amount, it is determined that the demand can be met; otherwise, it is determined that the demand cannot be met.

[0020] Preferably, the system further includes a request receiving and verification unit;

[0021] When the request receiving and verification unit operates, it accepts energy management requests sent by external systems. These requests include energy data descriptions, control parameters, and unique identification codes.

[0022] The energy management request is checked for parameter validity. If the check passes, the request is stored in the energy demand database and its status is set to pending. At the same time, a record containing a unique identification code and resource identifier is generated. If the check fails, the request is stored in the energy demand database and its status is set to invalid.

[0023] Import all energy management requests in the pending state into the pending demand queue.

[0024] Preferably, the system further includes a task execution unit;

[0025] When the task execution unit operates, the currently active resource instance obtains the corresponding energy demand from the pending demand queue, updates its status to "processing", and performs energy allocation actions.

[0026] Once all energy demands in the processing state have been processed, the resource instance transitions to sleep mode.

[0027] Preferably, the task execution unit also handles the following situations:

[0028] When a new energy management request with a pending status is added to the pending demand queue, a new task alert is issued, activating the corresponding resource instance that is in dormant mode;

[0029] The activated resource instance attempts to obtain energy requirements and checks whether there are matching pending energy requirements in the requirement list;

[0030] If there is no matching requirement, it is determined whether the requirement has not been obtained within the predetermined number of repetitions. If the number of repetitions has not been reached, the count is incremented and the acquisition is retried. If the number of repetitions has been reached, the instruction to put the resource instance into sleep mode is triggered.

[0031] If there is a matching requirement, the activated resource instance will obtain the requirement, change its status to "processing", execute the processing operation, and update the record status according to whether the processing result is normal. If the result is abnormal, the retry logic will be started.

[0032] Preferably, the real-time monitoring data includes energy consumption, supply efficiency, actual transmission rate, unresponsive demand, and demand latency.

[0033] Preferably, when the scheduling confirmation module checks whether the allocated resource category is located in the top region of the resource priority sequence, it dynamically adjusts the boundary threshold of the top region based on the real-time system load rate and demand completion rate.

[0034] Preferably, when the demand aggregation module merges the resource categories associated with the energy demand to be processed with the already allocated resource categories, it performs the following steps:

[0035] Obtain all energy management requests in the energy demand database that are in a pending state, and extract the resource category identifier declared by each request;

[0036] Query all resource records in the resource status database that are in the assigned status, and extract the resource category identifier corresponding to each record;

[0037] Perform a union operation between the extracted set of resource category identifiers to be processed and the set of assigned resource category identifiers to remove duplicate identifiers, and generate a set of resource categories to be assigned.

[0038] Attach a timestamp to each resource category identifier in the resource category set to record the exact moment when the category was included in the set.

[0039] Preferably, when the resource demand analysis module calculates the amount of energy demand that can be processed for the current resource category within a specified time interval, it further includes:

[0040] Get the unit time processing capacity parameter of the current resource category. This parameter represents the amount of energy demand that a single resource instance can process per unit time.

[0041] Multiply the unit time processing capacity parameter by the duration of the specified time interval to obtain the theoretical processing capacity of a single resource instance within the specified time interval.

[0042] Queries the number of active resource instances under this resource category;

[0043] Multiply the theoretical processing capacity by the number of active resource instances to obtain the total energy demand that the current resource category can handle within a specified time interval.

[0044] Compared with the prior art, the beneficial effects of the present invention are:

[0045] By continuously receiving real-time monitoring data from all aspects of the system—source, network, load, storage, and utilization—and using this data to dynamically assess the importance of resource categories to be allocated, the resource priority sequence can accurately reflect the current operational status and urgency of needs. Relatively minor loads in the static priority list may be identified as critical needs under specific operating conditions, while the priority of certain normally important loads can be appropriately reduced when the system has sufficient capacity. This dynamic assessment mechanism ensures that resource allocation decisions are no longer static mappings detached from reality, but rather dynamic processes closely coupled with the real-time state of the system, improving the accuracy and context-specific relevance of control decisions.

[0046] When the total available energy is insufficient to meet current high-priority needs, the system scans and revokes less important instances of allocated resources, releasing resources to ensure more critical needs are met. This mechanism breaks the rigid pattern of traditional allocation, enabling dynamic flow of resources among different priority needs. The system possesses the ability to optimize and reallocate internal resources under constraints, avoiding overall performance degradation caused by resource locking. This adaptive adjustment ensures that during periods of energy shortage, limited energy can be directed to the most critical aspects for stable system operation or core user interests, thereby enhancing the system's resilience to emergencies and the efficiency of resource utilization. Attached Figure Description

[0047] Figure 1 This is a schematic diagram illustrating the working principle of the intelligent control system for distributed energy management based on the integration of source, grid, load, storage, and utilization as described in this invention.

[0048] Figure 2 A flowchart for evaluating the importance of the priority ranking module;

[0049] Figure 3 A flowchart for integrating resource categories in the requirements aggregation module;

[0050] Figure 4 The dynamic boundary threshold adjustment diagram for the scheduling confirmation module;

[0051] Figure 5 This is a graph assessing the processing capacity of the resource demand analysis module. Detailed Implementation

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

[0053] Please see Figure 1This invention provides an intelligent control system for distributed energy management based on the integration of power generation, grid, load, storage, and utilization. The system includes: a demand aggregation module that first accesses an energy demand database to obtain the resource categories associated with the current energy demand to be processed, and simultaneously queries a resource status database to obtain the currently allocated resource categories. Then, it merges the resource categories associated with the energy demand to be processed with the allocated resource categories, removing duplicates to generate a set of resource categories to be allocated. A priority ranking module continuously receives real-time monitoring data from each link of the power generation, grid, load, storage, and utilization system, including energy consumption, supply efficiency, actual transmission rate, unresponsive demand, and demand latency. Using this data, it assesses the importance of each resource category in the set of resource categories to be allocated, generating a resource priority sequence. A resource demand analysis module selects resource categories one by one according to the order of the resource priority sequence, analyzing whether the energy demand corresponding to that resource category can be met within a specified time interval. If it can be met, it is marked as a single resource instance allocation; if it cannot be met, it determines that multiple resource instances are needed and calculates the required number of instances. The resource adjustment module checks the total available energy based on the required number of resource instances. If sufficient, it allocates a resource instance. If insufficient, it scans the currently allocated resource categories for instances with lower importance. If such instances exist, their allocation is revoked and the total available energy is rechecked. If none exist, the scheduling operation is interrupted. The scheduling confirmation module checks if all allocated resource categories are at the top of the resource priority sequence. If so, the scheduling process terminates; otherwise, it relays the feedback to the resource demand analysis module to continue processing subsequent resource categories in the sequence until the entire sequence has been checked.

[0054] Example 1: See Figure 2In practical implementation, the priority ranking module extracts the share of energy consumption in global consumption, the share of supply efficiency in global efficiency, the share of actual transmission rate in global rate, the share of unresponsive demand in global demand, and the share of demand latency in global duration for each resource category. This extraction process is completed by accessing real-time monitoring data streams. The real-time monitoring data includes energy consumption, supply efficiency, actual transmission rate, unresponsive demand, and demand latency. This data is continuously collected from sensors or monitoring systems at each stage of the power generation, grid, load, storage, and utilization process and stored in a distributed database. The share calculation uses a proportional method. For each resource category, the share of energy usage in global usage equals the energy usage of that resource category divided by the total energy usage of all resource categories. The share of supply efficiency in global efficiency equals the supply efficiency of that resource category divided by the average supply efficiency of all resource categories. The share of actual transmission rate in global rate equals the actual transmission rate of that resource category divided by the maximum transmission rate of all resource categories. The share of unresponsive demand in global demand equals the unresponsive demand of that resource category divided by the total unresponsive demand of all resource categories. The share of demand latency in global duration equals the demand latency of that resource category divided by the maximum demand latency of all resource categories. After calculation, each share is merged using predefined influence factors. These influence factors are weighted values ​​set by the system administrator based on business strategies. For example, the influence factor for energy usage share might be set to 0.3, the influence factor for supply efficiency share to 0.2, the influence factor for actual transmission rate share to 0.2, the influence factor for unresponsive demand share to 0.15, and the influence factor for demand latency share to 0.15. Fusion computing is achieved through weighted summation. The priority value of each resource category is equal to the sum of the following: energy usage share multiplied by its corresponding influence factor; supply efficiency share multiplied by its corresponding influence factor; actual transmission rate share multiplied by its corresponding influence factor; unresponsive demand share multiplied by its corresponding influence factor; and demand latency share multiplied by its corresponding influence factor. Based on the priority values, resource categories are sorted in descending order to form a resource priority sequence. The sorting algorithm uses quicksort or heapsort to ensure efficiency. The resource priority sequence is stored in memory for subsequent modules to access.

[0055] In some embodiments, the resource demand analysis module, when analyzing whether pending energy demands can be met within a specified time interval, implements the following steps: calculating the number of energy demands that the current resource category can handle within the specified time interval; comparing the number of handleable energy demands with the total number of pending energy demands; and making a judgment based on the comparison result. When calculating the number of energy demands that the current resource category can handle within the specified time interval, this number is obtained by multiplying the processing capacity of the resource category by the specified time interval. The processing capacity of the resource category is obtained from the resource status database, representing the number of energy demands that a single resource instance can handle per unit time. The specified time interval is defined by system configuration parameters or dynamically adjusted according to real-time load. The product calculation uses arithmetic multiplication; for example, if the processing capacity is 10 demands per second and the specified time interval is 60 seconds, then the number of handleable energy demands is 600. During the comparison process, the number of handleable energy demands is compared with the total number of pending energy demands, which is statistically derived from the energy demand database and covers all requests in the pending state. If the amount of energy demand that can be processed is greater than or equal to the total amount of energy demand to be processed, it is determined that the demand can be met, and the resource demand analysis module identifies the resource category as a single resource instance allocation. If the amount of energy demand that can be processed is less than the total amount of energy demand to be processed, it is determined that the demand cannot be met, and the resource demand analysis module determines that multiple resource instances are needed and calculates the number of instances required. The number of instances required is calculated by dividing the total amount of energy demand to be processed by the amount of energy demand that can be processed and rounding up. For example, if the total amount is 1000 and the amount that can be processed is 600, then the number of instances required is 2.

[0056] It is understandable that the importance assessment process of the priority ranking module relies on the accuracy and completeness of real-time data, and the system periodically verifies the data source to prevent errors. The analysis steps of the resource demand analysis module emphasize time sensitivity, and the specified time interval may be shortened or extended based on priority or external events. In specific implementation, if the global value is zero or invalid when extracting shares, the system uses the default value or skips the resource category to avoid division by zero errors. The setting of influencing factors supports dynamic updates and can be adjusted through the management interface to adapt to policy changes. The priority values ​​generated after fusion calculation are normalized to ensure that the values ​​are within the range of 0 to 1 for easy comparison. The generation frequency of the resource priority sequence is configurable, for example, updated once per second or per minute to reflect real-time changes. In the calculation of the resource demand analysis module, the processing capacity parameter may consider the current load of the resource instance, using the actual available capacity rather than the theoretical maximum value. After comparison and judgment, if it is identified as a single resource instance allocation, the system immediately triggers the resource allocation process; if multiple resource instances are required, the system resource limit is checked when calculating the number to avoid over-allocation.

[0057] Optionally, the share extraction process includes a data cleaning step to remove outliers or duplicate records. Influence factor fusion calculations support non-linear combinations, such as using multiplication or exponential functions to enhance the weight of key shares. Resource priority sequences are stored in a compressed format to reduce memory usage. The specified time interval for the resource demand analysis module can be parsed from energy management requests, prioritizing the time limit values ​​in the requests. When calculating the number of energy demands that can be processed, if a resource instance is in a faulty state, its processing capacity is set to zero. In the comparison judgment, if the total number of energy demands to be processed is zero, the system automatically marks it as satisfied to avoid redundant operations. When estimating the required number of instances, if the calculated result is a decimal, it is rounded up before verifying instance availability.

[0058] In some embodiments, the priority ranking module uses a sliding window averaging method to smooth data fluctuations and improve stability. The resource category processing capability of the resource requirement analysis module is calibrated through benchmark testing to ensure accuracy. The entire implementation process integrates logging functionality to track the execution status of each step for auditing purposes. It is understood that the implementation of this embodiment relies on data flow synchronization between modules; the priority ranking module and the resource requirement analysis module exchange information via message queues or shared memory. In specific implementations, the descending order of resource priority sequences uses a stable sorting algorithm to maintain the original order of resources with the same priority. The judgment results of the resource requirement analysis module are fed back to the resource adjustment module, forming a closed-loop control. The global value calculation cycle for share extraction is aligned with the system heartbeat cycle to reduce performance overhead. Support vector machines or regression models for influencing factor fusion calculation can be used to optimize weight allocation, but the basic implementation uses fixed weights. The dynamic adjustment of the resource requirement analysis module within a specified time interval is based on historical completion time predictions to improve adaptability.

[0059] Example 2: In specific implementation, the request receiving and verification unit accepts energy management requests sent by external systems through a predefined application programming interface endpoint. The energy management request is encapsulated in JavaScript object representation format and includes three main parts: an energy data description field recording the essential characteristics of the demand, such as energy type as electricity, demand quantity as 100 kWh, and urgency level as high; a control parameter field containing execution parameters, such as the maximum allowed response time as 300 seconds and a priority energy storage device flag set to true; and a unique identification code field, a 128-bit unique identifier generated by the external system. Upon accepting the request, the energy management request is immediately checked for parameter validity. The check process consists of three consecutive stages: the first stage verifies data format compliance, ensuring that the energy data description conforms to the predefined pattern specification, the data type of the control parameters matches system requirements, and the unique identification code conforms to the general unique identifier format; the second stage verifies the rationality of parameter value ranges, confirming that the energy demand is within the positive range that the system can process, the time parameter does not exceed the maximum allowed threshold, and the control parameter values ​​are within the valid enumeration set; the third stage checks the uniqueness of the code, querying the energy demand database historical records to prevent duplicate submissions. If all three phases of checks pass, the request is stored in the pending partition of the energy demand database, and its status is set to "pending." A complete record containing a unique identifier and resource identifier is generated, with the resource identifier automatically mapped to the corresponding resource category based on the energy type. If any phase fails, the request is stored in the invalid request archive partition of the energy demand database, and its status is set to "invalid." An error code is generated to record the reason for the failure. The system periodically scans the energy demand database, importing all energy management requests with the "pending" status into the memory structure of the pending demand queue in timestamp order, maintaining the integrity of the original request data during the import process.

[0060] The task execution unit runs continuously through an independent thread pool. Currently active resource instances periodically retrieve corresponding energy demands from the head of the pending demand queue, with atomic operations used to ensure thread safety during the retrieval process. Upon retrieving an energy demand, the resource instance immediately updates the status attribute of that record in the energy demand database to "processing" and begins executing energy allocation actions. These actions include calculating the required energy allocation, sending control commands to the target energy device, and confirming the device's response status. The execution of energy allocation actions employs a step-by-step verification mechanism; each step proceeds only after its success. Once all energy demands with the "processing" status attribute have been processed, the resource instance releases its occupied system resources, clears temporary data, and switches its operating mode to sleep mode to reduce energy consumption. In specific implementation, the verification logic for energy management requests can be used to calculate a comprehensive verification score using the following formula:

[0061]

[0062] in: The overall verification score representing the request. Weighting factors representing format compliance Represents format compliance indicators, Weighting factors representing the reasonableness of the value range Represents the reasonableness index of the value range. Weighting factors representing code uniqueness This represents the uniqueness metric of the code. When the overall verification score is... If the value exceeds the set threshold, the check is considered passed.

[0063] In some embodiments, the request receiving and verification unit adopts an asynchronous processing mode, immediately returning a receipt confirmation after accepting the request, while the verification operation is performed in a background thread to reduce the waiting time for external systems. Resource instances of the task execution unit maintain a minimum heartbeat signal in sleep mode, periodically reporting their liveness status to the control center, and can be quickly woken up when a new entry appears in the pending demand queue. The unique identification code for energy management requests is generated using a hybrid algorithm combining timestamps and random numbers to ensure global uniqueness in a distributed environment. Resource identifier allocation follows preset mapping rules, such as mapping electricity demand to photovoltaic power generation resource categories and thermal demand to geothermal resource categories. The pending demand queue is implemented using persistent message queue technology to prevent data loss in the event of system failure.

[0064] It is understandable that the strictness of parameter validity checks directly affects system security; overly lenient checks may allow abnormal requests to enter the processing flow. Partition management of the energy demand database optimizes data retrieval efficiency, and indexing the pending partitions speeds up queries. Atomic operations in the task execution unit prevent conflicts caused by multiple resource instances simultaneously acquiring the same energy demand. Resource instances in hibernation mode retain their last processing context, allowing for rapid recovery upon reactivation. In practice, external systems sending energy management requests must include a digital signature; the request receiving and verification unit verifies the signature's validity before performing parameter checks. The energy data description field supports an extended structure to accommodate special parameters for new energy types. The enumerated value set of the control parameter field supports hot updates, allowing for the expansion of new parameters without restarting the system. Verification of the unique identification code includes checking the validity of the code issuer's digital certificate. The invalid request archive partition of the energy demand database is configured with an automatic cleanup strategy, periodically removing expired invalid request records.

[0065] Optionally, the request receiving and verification unit sends a detailed error report to the external system when a check fails, indicating the specific failed check item and suggested corrections. When the resource instance in the task execution unit updates its status attribute to "processing," it simultaneously records the timestamp of the start of processing and the resource instance identifier for performance monitoring and troubleshooting. The import operation of the pending request queue supports batch processing mode, importing multiple energy management requests at once to reduce the number of database accesses. When a resource instance performs energy allocation actions, if it encounters abnormal situations such as device communication timeout or refusal to execute, it will automatically retry a limited number of times and record the result of each retry. Before transitioning to hibernation mode, resource instances in hibernation mode execute a resource cleanup routine, releasing open network connections and file handles.

[0066] In some embodiments, the energy data description field of the energy management request supports internationalization encoding, enabling the handling of energy demands described in multiple languages. The value range rationality check of the control parameter field uses a configurable rule engine, supporting the definition of complex logical conditions. The uniqueness verification range of the unique identification code can be set to globally unique or session-unique, flexibly adjusted according to the system deployment scale. The memory structure of the pending demand queue is implemented using a circular buffer; when the queue is full, the oldest request is automatically overwritten and the overwrite event is recorded. Resource instances of the task execution unit support a priority preemption mechanism when acquiring energy demands; high-priority demands can interrupt the processing of low-priority demands.

[0067] It is understandable that the collaborative work of the request receiving and verification unit and the task execution unit constitutes a complete request processing pipeline. The request receiving and verification unit is responsible for front-end receiving and verification, while the task execution unit is responsible for back-end execution and resource management. In specific implementations, energy management requests are stored using sharding technology, allowing large-scale deployments to distribute the energy demand database across multiple database nodes. The resource instance size of the task execution unit supports elastic scaling, dynamically adjusting the number of active instances based on the length of the pending demand queue. The execution results of energy allocation actions are fed back to update the request records in the energy demand database, recording the final processing status and actual energy consumption data. The entire implementation emphasizes the reliability and efficiency of request processing, ensuring input quality through rigorous verification and execution consistency through state management.

[0068] Optionally, the request receiving and verification unit can temporarily reduce the stringency of checks under high pressure to prioritize system availability. Resource instances in the task execution unit support a graceful shutdown mechanism; upon receiving a shutdown command, they complete the currently processed energy requirement before entering sleep mode. The pending partition of the energy requirement database implements read-write separation to improve concurrent access performance. Resource instances use an asynchronous confirmation mode when performing energy allocation actions; after sending control commands, they do not block and wait for an immediate response, but instead handle subsequent responses through callback functions. Resource instances in sleep mode periodically check the length of the pending requirement queue; when the length exceeds a threshold, they are automatically activated to speed up processing.

[0069] Example 3: In specific implementation, when a new energy management request with a pending status is added to the pending demand queue, the system detects changes in queue length through an event listening mechanism and immediately issues a new task alert. The new task alert is broadcast via message queue and includes the request identifier and resource category information. The new task alert is transmitted to the resource instance management pool, activating the corresponding resource instance in dormant mode. The activation process includes allocating computing resources, loading the processing context, and initializing network connections. For example, when an electricity demand request is added to the queue, and the new task alert specifies the resource category as photovoltaic power generation, the system activates a dormant photovoltaic power generation resource instance. After the activated resource instance starts, it attempts to acquire the energy demand by querying the head entry of the pending demand queue and checking if a matching pending energy demand exists in the demand list. The matching criterion is based on the consistency of the resource category identifier and the demand attribute. The demand list is dynamically generated from the energy demand database. If no matching requirement exists, the resource instance checks if the requirement has not been obtained within a predetermined number of repetitions. The predetermined number of repetitions is set to a fixed value in the system configuration file, such as 5 times. If the predetermined number of repetitions has not been reached, the internal counter is incremented and the instance retryes to obtain the requirement. Before retrying, a delay period is waited, and the delay period is calculated using the following formula:

[0070]

[0071] in: Represents the delay time in seconds. Represents the fundamental delay time constant. Represents the multiplier factor. This represents the current retry count. If the predetermined number of retryes is reached, an instruction is triggered to put the resource instance into sleep mode. This instruction includes saving the state, releasing resources, and deregistering the instance. If there is a matching demand, the activated resource instance obtains the demand, changes its status to "processing," updates the record status field in the energy demand database, and performs processing operations, including verifying demand parameters, allocating energy quotas, sending control commands, and updating the record status based on whether the processing result is normal. If the processing result is normal, the status is set to "complete." If the result is abnormal, retry logic is initiated, which includes a limited number of retry attempts and error reporting.

[0072] In some embodiments, new task alerts are issued using a priority channel; high-priority requests trigger immediate alerts, while low-priority requests are processed in batches. When activating a dormant resource instance, the system checks the instance's health status and only activates instances that pass the health check. During the matching detection process, the demand list uses a caching mechanism to improve query speed and is periodically refreshed to avoid outdated data. The retry logic's retry count is configurable, with different predetermined repetition counts set for different resource categories. Real-time monitoring data includes energy usage, supply efficiency, actual transmission rate, unresponsive demand volume, and demand latency. This data is collected in real-time from a distributed sensor network. Energy usage is recorded in kilowatt-hours, supply efficiency is expressed as a percentage, actual transmission rate is measured in megawatts per second, unresponsive demand volume is counted by the number of requests, and demand latency is calculated in seconds. Monitoring data is stored in a time-series database for use by the priority sorting module.

[0073] It is understandable that the triggering of new task alerts relies on precise notifications from the queue management system, with the queue implemented as a thread-safe data structure. The process of activating a dormant instance requires atomic operations to prevent race conditions, and a locking mechanism is used for serialization when multiple instances are activated simultaneously. The matching detection algorithm is optimized to a hash lookup, reducing time complexity. The delay calculation for retry logic avoids over-congestion, and a multiplier factor greater than 1 is chosen to achieve exponential backoff. The criteria for judging a normal processing result include the device response code and the energy allocation confirmation signal. The collection frequency of real-time monitoring data is adjustable, with increased sampling rate during peak periods. In specific implementations, new task alerts include timestamps and source information for audit tracing. When activating a dormant instance, if instance initialization fails, the system records the error and attempts a backup instance. In matching detection, invalid or expired requests are filtered out during the generation of the demand list. The retry counter is reset under the conditions of successfully acquiring a demand or triggering a dormant command. During processing operations, resource instances monitor their own resource utilization to prevent overload.

[0074] Optionally, new task alerts support an acknowledgment mechanism; the alert is only marked as processed after the recipient confirms. Activating dormant instances includes a warm-up phase, gradually increasing instance load to avoid cold start issues. Match detection supports fuzzy matching to handle minor differences in resource category identifiers. The latency calculation for retry logic introduces random jitter to avoid simultaneous retries across multiple instances. Judgment of abnormal processing results includes timeout and error code classification; different error types trigger different retry strategies. Data transmission for real-time monitoring uses compression protocols to reduce bandwidth consumption.

[0075] In some embodiments, the format of new task alerts is standardized to a protocol buffer format to improve parsing efficiency. Resource allocation for activating dormant instances utilizes containerization technology for rapid deployment. Match detection queries are optimized for parallel scanning, leveraging multi-core processors. The predetermined number of retry iterations in the retry logic is dynamically adjusted based on system load, reducing the number of retries when the load is high. Processing results are logged in detail, including start time, end time, and energy consumption data. Real-time monitoring data is stored using a sharding strategy, supporting horizontal scaling.

[0076] Understandably, the task execution unit's processing flow ensures efficient utilization of resource instances, rapidly responding to new demands through alerts and activation mechanisms. Matching detection reduces unnecessary instance wake-ups, saving system resources. Retry logic improves robustness and handles temporary failures. Real-time monitoring data provides a basis for decision-making, supporting dynamic adjustments. In specific implementation, listeners for new task alerts are deployed on multiple nodes to achieve high availability. Instructions to activate dormant instances are sent via remote procedure calls, supporting distributed deployment. The index structure for matching detection uses a B-tree to accelerate range queries. The retry counter for the retry logic is persistently stored to prevent data loss upon system restarts. The processing results of the operations are reported to the monitoring center, displaying the system status in real time. The data cleaning process for real-time monitoring data removes outliers, ensuring data quality.

[0077] Optionally, the priority of new task alerts is mapped to resource category priority, with higher-priority resources receiving alerts first. When activating a dormant instance, if the instance pool is insufficient, the system automatically creates a new instance. The matching detection algorithm supports machine learning models, optimizing matching accuracy based on historical data. The latency calculation for retry logic references network latency metrics, adaptively adjusting the base latency constant. A notification mechanism is triggered when the processing operation's result is normal, informing external systems of the completion status. Real-time monitoring data analysis utilizes a stream processing engine to calculate key metrics in real time.

[0078] Example 4: See Figure 3In practical implementation, when the scheduling confirmation module checks whether all allocated resource categories are located in the top region of the resource priority sequence, it dynamically adjusts the boundary threshold of the top region based on the system's real-time load rate and demand completion rate. The system's real-time load rate is calculated as the ratio of the number of currently active resource instances to the total number of resource instances, and the demand completion rate is calculated as the ratio of the number of completed energy demands to the total number of submitted energy demands. The dynamic adjustment process uses a sliding window algorithm to monitor the load and completion rate trends within the most recent time interval. For example, when the system's real-time load rate is consistently higher than 80% and the demand completion rate is lower than 85%, the boundary threshold is automatically reduced to improve resource allocation efficiency. The top region is defined as the part with the highest priority value in the resource priority sequence, and the boundary threshold represents the proportion of resource categories included in the top region. The initial threshold is set to 30%, but it fluctuates between 10% and 50% based on real-time data. The verification logic is achieved by comparing the ranking of the allocated resource category in the sequence with the current threshold position. If the ranking is less than or equal to the position corresponding to the threshold, it is determined to be in the top region and the scheduling process is terminated; otherwise, it is fed back to the resource demand analysis module for further processing. The formula for dynamic adjustment is as follows:

[0079]

[0080] in: Represents the percentage of the boundary threshold. Represents the load factor weighting coefficient. Represents the real-time load rate of the system. The weighting coefficient represents the completion rate. This represents the requirement completion rate, with weighting coefficients preset according to the system strategy. For example, A is 0.6 and B is 0.4, emphasizing the greater impact of load rate. Value constraints are set within minimum and maximum threshold ranges to prevent over-adjustment. Threshold adjustments take effect immediately and are logged for auditing purposes. When the demand aggregation module merges the resource categories associated with pending energy demands with the allocated resource categories, the execution steps include retrieving all energy management requests in the pending energy demand database. The energy demand database is stored in a relational database, and each request contains a resource category identifier field such as "photovoltaic power generation" or "energy storage device." The extraction process uses structured query language to filter records with the status field "pending" and project the identifier field. Simultaneously, it queries all resource records in the resource status database with the status "allocated." The resource status database maintains the real-time status of resource instances, and the corresponding resource records for each record are extracted. The resource category identifier is obtained by performing a union operation between the extracted set of resource category identifiers to be processed and the set of assigned resource category identifiers. The union operation uses a hash set data structure to automatically remove duplicate identifiers, generating a set of resource categories to be assigned. The elements of the set are sorted in lexicographical order by identifiers to ensure consistency. A timestamp is attached to each resource category identifier in the resource category set. The timestamp uses the current system time to the millisecond to record the specific time when the category was included in the set. The timestamp is used by subsequent modules to evaluate the freshness of the requirements. For example, in the priority sorting module, categories with later timestamps may receive higher priority. The entire fusion process is executed periodically or triggered by new request events to ensure the real-time performance of the set.

[0081] In some embodiments, the dynamic adjustment mechanism of the scheduling confirmation module integrates a machine learning model, uses historical load rate and completion rate data to train and predict boundary thresholds, and improves adjustment accuracy. The union operation of the demand aggregation module supports distributed processing. When the energy demand database and resource status database are stored in shards, data is extracted in parallel to speed up the fusion process. The additional timestamp includes time zone information to adapt to global deployment scenarios. Refer to Table 1, the boundary threshold adjustment correspondence table, to show typical threshold values ​​under different combinations of load rate and completion rate.

[0082] Table 1: Correspondence Table for Boundary Threshold Adjustment

[0083]

[0084] It is understandable that the verification process of the scheduling confirmation module relies on the real-time update of the resource priority sequence. When the sequence changes, the assigned categories are re-verified to avoid using outdated data. In the fusion step of the demand aggregation module, the identifier extraction uses batch operations to reduce the number of database accesses. The storage of timestamps adopts a compact format to save memory space. The dynamically adjusted weight coefficients can be modified online through the management interface to adapt to the needs of different operation and maintenance stages. The data in the threshold adjustment corresponding table is generated based on offline analysis, but formula calculation is used in the online stage to achieve fine-grained control.

[0085] In some embodiments, the verification results of the scheduling confirmation module are cached for a period of time to reduce redundant calculation overhead. The set of resource categories to be allocated in the demand aggregation module is serialized and stored, supporting fast serialization and deserialization for inter-module transmission. The timestamp is encoded using an international standard time format to avoid local time ambiguity. It can be understood that the scheduling confirmation module and the demand aggregation module work together asynchronously via a message bus, ensuring module decoupling and system scalability. The coefficient calibration of the dynamically adjusted formula is optimized using A / B testing. The fusion logic of the demand aggregation module integrates transaction features to ensure data consistency.

[0086] See Figure 4 This diagram illustrates the dynamic process by which the scheduling confirmation module intelligently adjusts resource allocation boundary thresholds based on system operating status. The figure clearly shows the trends of three key curves—real-time system load rate, demand completion rate, and dynamic boundary threshold—over time, reflecting how the system adaptively optimizes its resource allocation strategy based on real-time operating conditions. When the system load is high and demand completion efficiency is insufficient, the boundary threshold automatically shrinks to improve allocation efficiency; conversely, during stable operating periods, the threshold range is appropriately widened to fully utilize resources, demonstrating the system's adaptive capability and stability in intelligent regulation.

[0087] Example 5: In specific implementation, when the resource demand analysis module calculates the amount of energy demand that the current resource category can handle within a specified time interval, it first obtains the unit-time processing capacity parameter of the current resource category. The unit-time processing capacity parameter represents the amount of energy demand that a single resource instance can handle per unit time. The parameter value is read from predefined fields in the resource configuration library. For example, the unit-time processing capacity parameter for the photovoltaic power generation resource category might be 50 energy demands per hour, and the unit-time processing capacity parameter for the energy storage device resource category might be 30 energy demands per hour. The resource configuration library uses a key-value pair storage structure, where the key... The resource category identifier is used, and the value is the processing capacity parameter and its metadata. The acquisition process includes verifying the validity and timeliness of the parameter to ensure that the parameter value is within a reasonable range and has not expired. Then, the processing capacity parameter per unit time is multiplied by the duration of a specified time interval. The duration of the specified time interval is dynamically determined by the system scheduling policy or parsed from the energy management request, such as 8 hours or 7200 seconds. The multiplication operation yields the theoretical processing capacity of a single resource instance within the specified time interval. The theoretical processing capacity represents the maximum amount of energy demand that a single resource instance can handle within the specified time interval under ideal conditions. The calculation process uses the following formula:

[0088]

[0089] in: This represents the total amount of energy demand that the current resource category can handle within a specified time interval. This parameter represents the processing capacity per unit of time. Represents the duration of a specified time interval. This represents the number of active resource instances under the current resource category. Querying the number of active resource instances under the current resource category is accomplished by scanning the resource status database. The resource status database maintains real-time status records of all resource instances, including active, dormant, and faulty states. The query conditions are set to match the resource category identifier and the status field is "active". The query result returns the number of resource instances that meet the conditions. Finally, the theoretical processing capacity is multiplied by the number of active resource instances to obtain the total energy demand that the current resource category can handle within the specified time interval. The entire calculation process is executed under transaction protection to prevent data inconsistency.

[0090] In some embodiments, the acquisition of the unit time processing capacity parameter includes a version control mechanism. When the parameter is updated, the system automatically switches to the new version and records the change history. The duration value of the specified time interval supports multiple time unit conversions, such as converting hours to seconds or days to minutes, to ensure the uniformity of the calculation unit. The calculation of the theoretical processing capacity takes into account the performance decay factor of the resource instance. A discount coefficient is introduced for instances with longer running times. The query of the number of active resource instances uses caching technology to improve performance. The cache is refreshed regularly to ensure data freshness. The calculation result of the total energy demand is rounded to an integer, because the energy demand must be an integer value.

[0091] It is understandable that the accuracy of the unit time processing capacity parameter directly affects the reliability of the calculation results. The parameter is calibrated regularly through benchmark testing. The duration of a specified time interval may be affected by external factors such as weather conditions or power grid policies, and needs to be dynamically adjusted. The theoretical processing capacity is an ideal value, and the actual processing capacity may be reduced due to network latency or equipment failure. The real-time query of the number of active resource instances reflects the current available resource level of the system. The total energy demand is used for subsequent resource allocation decisions and is the core output of the resource demand analysis module.

[0092] Optionally, the storage of the unit time processing capacity parameter adopts a distributed configuration center, which supports synchronous updates of multiple nodes. The duration value of the specified time interval is set with upper and lower limits to prevent calculation abnormalities caused by excessively long or short durations. The intermediate results of the calculation of theoretical processing capacity are recorded for debugging purposes. The query of the number of active resource instances is implemented as an asynchronous operation to avoid blocking the main thread. The calculation log of the total energy demand includes input parameters and output values ​​for easy auditing.

[0093] In practice, the resource demand analysis module periodically recalculates the total energy demand. Recalculation is triggered when changes in the unit time processing capacity parameter, adjustments to the specified time interval, or changes in the number of active resource instances are detected. If anomalies occur during the calculation process, such as invalid parameters or database connection failures, the system uses the previous valid calculation result and issues an alarm. The unit time processing capacity parameter may be updated due to resource instance upgrades or load changes. The update process includes verifying the rationality of the new parameters and obtaining approval before they take effect. The duration value of the specified time interval is obtained from the scheduling strategy. The strategy supports intelligent recommendations based on historical data. The query for the number of active resource instances includes health checks, and only instances that have passed the health checks are counted. The accuracy of the calculation result of the total energy demand is controlled to the integer part, and the decimal part uses an up-rounding strategy to avoid underestimating the demand.

[0094] See Figure 5 This section showcases the comprehensive evaluation results of the resource demand analysis module on the processing capabilities of different types of resources. By displaying three key dimensions—unit processing capacity, number of active instances, and total processing capacity—for each resource category, it clearly reveals the characteristic differences and overall efficiency of various resources in energy demand processing. The charts intuitively reflect the differences in processing efficiency per unit time, the current available resource scale, and the overall processing potential of different resource categories, providing important quantitative basis for the system to make scientific and reasonable resource allocation and scheduling decisions, ensuring that energy demand can be met in a timely and effective manner.

[0095] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A distributed energy management and intelligent control system based on the integration of source, grid, load, storage, and utilization, characterized in that: The system includes; The demand aggregation module accesses the energy demand database to obtain the resource categories associated with the current energy demand to be processed, and at the same time queries the resource status database to obtain the currently allocated resource categories. It then merges the resource categories associated with the energy demand to be processed with the allocated resource categories to generate a set of resource categories to be allocated. The priority ranking module continuously receives real-time monitoring data from each link of the source, grid, load, storage and utilization, and uses the real-time monitoring data to evaluate the importance of each resource category in the set of resource categories to be allocated, and generates a resource priority sequence. The resource demand analysis module selects resource categories one by one according to the order of resource priority sequence, analyzes whether the energy demand to be processed corresponding to the resource category can be met within the specified time interval. If it can be met, it is marked as a single resource instance allocation. If it cannot be met, it is determined that multiple resource instances are needed, and the number of required instances is estimated. The resource adjustment module checks whether the total available energy is sufficient based on the number of required resource instances. If sufficient, it allocates a resource instance. If insufficient, it scans for instances of lower importance than the current resource category among the currently allocated resource categories. If such instances exist, it cancels their allocation and rechecks the total available energy. If none exist, it interrupts the current scheduling operation. The scheduling confirmation module checks whether all allocated resource categories are at the top of the resource priority sequence. If so, the scheduling process is terminated; otherwise, the process is fed back to the resource demand analysis module to continue processing subsequent resource categories in the sequence until the entire sequence has been checked.

2. The intelligent control system for distributed energy management based on the integration of source, grid, load, storage, and utilization as described in claim 1, characterized in that, When the priority ranking module performs importance evaluation, it performs the following processing: For each resource category, extract its share of energy consumption in global consumption, supply efficiency in global efficiency, actual transmission rate in global rate, unresponsive demand in global demand, and demand latency in global duration. Using predefined impact factors, each share is aggregated and calculated to obtain the priority value for each resource category; Based on the priority values, the resource categories are arranged in descending order to form a resource priority sequence.

3. The intelligent control system for distributed energy management based on the integration of source, grid, load, storage, and utilization as described in claim 1, characterized in that, When analyzing whether the energy demand to be processed can be met within a specified time interval, the resource demand analysis module performs the following steps: Calculate the amount of energy demand that the current resource category can handle within a specified time interval. This amount is obtained by multiplying the processing capacity of the resource category by the specified time interval. Compare the amount of energy demand that can be processed with the total amount of energy demand to be processed; If the amount of energy demand that can be handled is greater than or equal to the total amount, it is determined that the demand can be met; otherwise, it is determined that the demand cannot be met.

4. The intelligent control system for distributed energy management based on the integration of source, grid, load, storage, and utilization as described in claim 1, characterized in that, The system also includes a request receiving and verification unit; When the request receiving and verification unit operates, it accepts energy management requests sent by external systems. These requests include energy data descriptions, control parameters, and unique identification codes. The energy management request is checked for parameter validity. If the check passes, the request is stored in the energy demand database and its status is set to pending. At the same time, a record containing a unique identification code and resource identifier is generated. If the check fails, the request is stored in the energy demand database and its status is set to invalid. Import all energy management requests in the pending state into the pending demand queue.

5. The intelligent control system for distributed energy management based on the integration of source, grid, load, storage, and utilization as described in claim 1, characterized in that, The system also includes a task execution unit; When the task execution unit operates, the currently active resource instance obtains the corresponding energy demand from the pending demand queue, updates its status to "processing", and performs energy allocation actions. Once all energy demands in the processing state have been processed, the resource instance transitions to sleep mode.

6. The intelligent control system for distributed energy management based on the integration of source, grid, load, storage, and utilization as described in claim 5, characterized in that, The task execution unit also handles the following situations: When a new energy management request with a pending status is added to the pending demand queue, a new task alert is issued, activating the corresponding resource instance that is in dormant mode; The activated resource instance attempts to obtain energy requirements and checks whether there are matching pending energy requirements in the requirement list; If there is no matching requirement, it is determined whether the requirement has not been obtained within the predetermined number of repetitions. If the number of repetitions has not been reached, the count is incremented and the acquisition is retried. If the number of repetitions has been reached, the instruction to put the resource instance into sleep mode is triggered. If there is a matching requirement, the activated resource instance will obtain the requirement, change its status to "processing", execute the processing operation, and update the record status according to whether the processing result is normal. If the result is abnormal, the retry logic will be started.

7. The intelligent control system for distributed energy management based on the integration of source, grid, load, storage, and utilization as described in claim 1, characterized in that, The real-time monitoring data includes energy consumption, supply efficiency, actual transmission rate, unresponsive demand, and demand latency.

8. The intelligent control system for distributed energy management based on the integration of source, grid, load, storage, and utilization as described in claim 1, characterized in that, When the scheduling confirmation module checks whether the allocated resource category is located in the top region of the resource priority sequence, it dynamically adjusts the boundary threshold of the top region based on the real-time system load rate and demand completion rate.

9. The intelligent control system for distributed energy management based on the integration of source, grid, load, storage, and utilization as described in claim 1, characterized in that, When the demand aggregation module merges the resource categories associated with the energy demand to be processed with the already allocated resource categories, it performs the following steps: Obtain all energy management requests in the energy demand database that are in a pending state, and extract the resource category identifier declared by each request; Query all resource records in the resource status database that are in the assigned status, and extract the resource category identifier corresponding to each record; Perform a union operation between the extracted set of resource category identifiers to be processed and the set of assigned resource category identifiers to remove duplicate identifiers, and generate a set of resource categories to be assigned. Attach a timestamp to each resource category identifier in the resource category set to record the exact moment when the category was included in the set.

10. The intelligent control system for distributed energy management based on the integration of source, grid, load, storage, and utilization as described in claim 3, characterized in that, When the resource demand analysis module calculates the amount of energy demand that can be processed for the current resource category within a specified time interval, it further includes: Get the unit time processing capacity parameter of the current resource category. This parameter represents the amount of energy demand that a single resource instance can process per unit time. Multiply the unit time processing capacity parameter by the duration of the specified time interval to obtain the theoretical processing capacity of a single resource instance within the specified time interval. Queries the number of active resource instances under this resource category; Multiply the theoretical processing capacity by the number of active resource instances to obtain the total energy demand that the current resource category can handle within a specified time interval.

Images