Power load control method based on hybrid communication architecture and related equipment

Abstract

The invention provides a power load control method based on a hybrid communication architecture and related equipment. The method comprises the following steps: receiving a service calling request from a service initiator; creating a service processing thread related to the service calling request; in response to the fact that the service type of the service calling request is determined to be local service, the service processing thread obtains first data for the service calling request based on a local shared memory area, generates a first return result based on the first data and sends the first return result to a first target node of the service calling request; and in response to determining that the service type of the service calling request is a cross-node service, the service processing thread generates a second return result for the service calling request, and sends the second return result to a second target node of the service calling request based on a network communication message queue.

Description

Technical Field

[0001] This disclosure relates to the field of communications, and in particular to a power load control method and related equipment based on a hybrid communication architecture. Background Technology

[0002] With the deepening of the construction of new power systems, the demand for load-side resources to participate in grid regulation is becoming increasingly prominent. Traditional power load control systems lack independent network channels, resulting in numerous data interaction links and long acquisition chains. This leads to inaccurate and untimely statistical analysis of execution effects, severely impacting the regulation, management, and service levels of load resources. Traditional power load control systems rely solely on single communication methods such as message queues, resulting in high local communication latency and low cross-node transmission efficiency. Furthermore, power load control service management is complex, lacking a unified registration and health monitoring mechanism, leading to poor service discovery and load balancing performance. In addition, general network communication frameworks lack optimization for power systems, failing to meet the real-time requirements of power load control. Summary of the Invention

[0003] In view of this, the purpose of this disclosure is to propose a power load control method and related equipment based on a hybrid communication architecture.

[0004] In a first aspect, this disclosure provides a power load control method based on a hybrid communication architecture, comprising: The service type of the service request received from the business is a local service. The service processing thread obtains the first data for the service call request based on the local shared memory area, and generates a first return result based on the first data and sends it to the first target node of the service call request. In response to determining that the service type of the service call request is a cross-node service, the service processing thread generates a second return result for the service call request and sends it to the second target node of the service call request based on the network communication message queue.

[0005] A second aspect of this disclosure provides an improved power load control device based on a hybrid communication architecture, comprising: The receiving module is used to receive service call requests from the business initiator. The thread module is used to create a service processing thread for the service call request; and In response to determining that the service type of the service call request is a local service, the service processing thread obtains the first data for the service call request based on the local shared memory area, and generates a first return result based on the first data and sends it to the first target node of the service call request. In response to determining that the service type of the service call request is a cross-node service, the service processing thread generates a second return result for the service call request and sends it to the second target node of the service call request based on the network communication message queue.

[0006] A third aspect of this disclosure provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the method as described in the first aspect.

[0007] In a fourth aspect, this disclosure provides a non-transitory computer-readable storage medium storing computer instructions for causing a computer to perform the method described in the first aspect.

[0008] A fifth aspect of this disclosure provides a computer program product including computer program instructions that, when executed on a computer, cause the computer to perform the method described in the first aspect.

[0009] As described above, this disclosure provides a power load control method and related equipment based on a hybrid communication architecture. It receives service call requests from service initiators and creates corresponding service processing threads. The processing is flexible based on the service type. For local services, the thread quickly obtains data, generates results, and sends them to the target node using local shared memory, leveraging the efficiency of shared memory to improve local service response. For cross-node services, the thread generates results and transmits them to the target node via a network communication message queue, ensuring reliable and orderly cross-network transmission. This effectively adapts to different service scenarios, balancing rapid local response with stable cross-node communication, thus improving the overall efficiency and stability of power load control. By providing a high-performance, highly reliable service bus, it deeply integrates the extreme performance of shared memory with the reliable scalability of message queues, meeting the rapid response requirements of real-time control messages in power load control systems while ensuring stability and business continuity during massive cross-node data transmission. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in this disclosure or related technologies, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the accompanying drawings described below are only embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a schematic diagram of a power load control architecture based on a hybrid communication architecture according to an embodiment of this disclosure.

[0012] Figure 2 This is a schematic diagram of the structure of an exemplary electronic device according to an embodiment of the present disclosure.

[0013] Figure 3 This is a schematic flowchart illustrating a power load control method based on a hybrid communication architecture according to an embodiment of this disclosure.

[0014] Figure 4 This is a schematic diagram of the service bus based on a hybrid communication architecture according to an embodiment of this disclosure.

[0015] Figure 5 This is a schematic diagram of a shared memory area according to an embodiment of the present disclosure.

[0016] Figure 6 This is a schematic diagram of cross-node process communication according to an embodiment of the present disclosure.

[0017] Figure 7 This is a schematic diagram of a power load control device based on a hybrid communication architecture according to an embodiment of this disclosure. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this disclosure clearer, the following detailed description is provided in conjunction with specific embodiments and the accompanying drawings.

[0019] It should be noted that, unless otherwise defined, the technical or scientific terms used in the embodiments of this disclosure should have the ordinary meaning understood by one of ordinary skill in the art to which this disclosure pertains. The terms "first," "second," and similar terms used in the embodiments of this disclosure do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed following the word and their equivalents, without excluding other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are used only to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0020] It is understood that before using the technical solutions disclosed in the various embodiments of this disclosure, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this disclosure in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.

[0021] For example, upon receiving a user's active request, a prompt message is sent to the user to explicitly inform them that the requested operation will require the acquisition and use of the user's personal information. This allows the user to independently choose whether to provide personal information to the software or hardware, such as the electronic device, application, server, or storage medium performing the operations of this disclosed technical solution, based on the prompt message.

[0022] It is understood that the above notification and user authorization process are merely illustrative and do not constitute a limitation on the implementation of this disclosure. Other methods that comply with relevant laws and regulations may also be applied to the implementation of this disclosure.

[0023] Figure 1 A schematic diagram of a power load control architecture based on a hybrid communication architecture, according to an embodiment of this disclosure, is shown. (Refer to...) Figure 1 The power load control architecture 100 based on a hybrid communication architecture may include a server 110, a terminal 120, and a network 130 providing communication links. The server 110 and the terminal 120 can be connected via a wired or wireless network 130. The server 110 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, security services, and CDN.

[0024] Terminal 120 can be implemented in hardware or software. For example, when terminal 120 is implemented in hardware, it can be various electronic devices with a display screen and support page display, including but not limited to smartphones, tablets, e-book readers, laptops, and desktop computers. When terminal 120 is implemented in software, it can be installed in the electronic devices listed above; it can be implemented as multiple software programs or software modules (e.g., software programs or software modules used to provide distributed services) or as a single software program or software module, without specific limitations.

[0025] It should be noted that the power load control method based on a hybrid communication architecture provided in this embodiment can be executed by the terminal 120 or by the server 110. It should be understood that... Figure 1 The number of terminals, networks, and servers shown is for illustrative purposes only and is not intended to be a limitation. Any number of terminals, networks, and servers can be used depending on implementation needs.

[0026] Figure 2 A schematic diagram of the hardware structure of an exemplary electronic device 200 provided in an embodiment of this disclosure is shown. For example... Figure 2As shown, the electronic device 200 may include: a processor 202, a memory 204, a network module 206, a peripheral interface 208, and a bus 210. The processor 202, memory 204, network module 206, and peripheral interface 208 are interconnected within the electronic device 200 via the bus 210.

[0027] Processor 202 may be a Central Processing Unit (CPU), a Neural Processing Unit (NPU), a Microcontroller (MCU), a programmable logic device, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), or one or more integrated circuits. Processor 202 can be used to perform functions related to the techniques described in this disclosure. In some embodiments, processor 202 may also include multiple processors integrated as a single logic component. For example, such as... Figure 2 As shown, processor 202 may include multiple processors 202a, 202b and 202c.

[0028] Memory 204 can be configured to store data (e.g., instructions, computer code, etc.). Figure 2 As shown, the data stored in memory 204 may include program instructions (e.g., program instructions for implementing the power load control method based on a hybrid communication architecture according to embodiments of this disclosure) and data to be processed (e.g., the memory may store configuration files of other modules, etc.). Processor 202 may also access the program instructions and data stored in memory 204 and execute the program instructions to operate on the data to be processed. Memory 204 may include volatile or non-volatile storage devices. In some embodiments, memory 204 may include random access memory (RAM), read-only memory (ROM), optical disk, magnetic disk, hard disk, solid-state drive (SSD), flash memory, memory stick, etc.

[0029] Network module 206 can be configured to provide communication with other external devices to electronic device 200 via a network. This network can be any wired or wireless network capable of transmitting and receiving data. For example, the network can be a wired network, a local wireless network (e.g., Bluetooth, WiFi, Near Field Communication (NFC), etc.), a cellular network, the Internet, or a combination thereof. It is understood that the type of network is not limited to the specific examples described above. In some embodiments, network module 206 may include any combination of any number of network interface controllers (NICs), radio frequency modules, transceivers, modems, routers, gateways, adapters, cellular network chips, etc.

[0030] The peripheral interface 208 can be configured to connect the electronic device 200 to one or more peripheral devices to enable information input and output. For example, peripheral devices may include input devices such as keyboards, mice, touchpads, touch screens, microphones, and various sensors, as well as output devices such as displays, speakers, vibrators, and indicator lights.

[0031] Bus 210 can be configured to transmit information between various components of electronic device 200 (e.g., processor 202, memory 204, network module 206, and peripheral interface 208), such as internal buses (e.g., processor-memory bus), external buses (USB port, PCI-E bus), etc.

[0032] It should be noted that although the architecture of the above-described electronic device 200 only shows the processor 202, memory 204, network module 206, peripheral interface 208, and bus 210, in specific implementations, the architecture of the electronic device 200 may also include other components necessary for normal operation. Furthermore, those skilled in the art will understand that the architecture of the above-described electronic device 200 may only include the components necessary for implementing the embodiments of this disclosure, and does not necessarily include all the components shown in the figures.

[0033] See Figure 3 , Figure 3 A schematic flowchart of a power load control method based on a hybrid communication architecture according to an embodiment of the present disclosure is shown. The power load control method based on a hybrid communication architecture according to an embodiment of the present disclosure can be deployed on a server. Figure 3 In the power load control method 300 based on a hybrid communication architecture, the following steps may be further included.

[0034] In step S310, a service call request is received from the service initiator.

[0035] In this context, the service initiator can refer to an entity within the power load control-related business scenario. For example, a power grid dispatch center might initiate a request to adjust user load based on the overall power grid operation and load forecast results; a large industrial user might proactively initiate a request to adjust their power load based on their production plan and electricity costs; or an automated control system might trigger a service call based on preset rules and real-time monitoring data. A service call request can be an instruction issued by the service initiator to the system to achieve a specific business objective. In power load control, a service call request may include operational requirements such as adjusting the specific value of user load in a certain area or controlling the switching of specific equipment, while also carrying necessary information such as the request initiation time, priority, target node, and data processing information.

[0036] In step S320, a service processing thread is created for the service call request.

[0037] The service processing thread can be a lightweight execution unit dynamically created for each independent service call request within the power load control system. It receives service call requests from the service initiator and creates a dedicated service processing thread for each received request, ensuring that each request receives independent processing resources and avoiding interference between requests.

[0038] Specifically, see Figure 4 , Figure 4 A schematic diagram of the structure of a service bus built on a network communication architecture according to an embodiment of the present disclosure is shown. Figure 4 In this system architecture based on a service bus, efficient interaction between clients and services is achieved through a service bus common library, while the stable operation of services is ensured by the service bus daemon. Specifically, the service bus provides a unified communication interface between clients and services. Clients initiate requests through the service bus common library, and the service bus is responsible for routing these requests to the appropriate services and returning the service responses to the clients.

[0039] Clients can be service request initiators within the system, such as various applications, devices, or user interfaces. They interact with services through the service bus public library, sending synchronous or asynchronous requests and receiving corresponding responses. Synchronous request / response: After sending a request, the client waits for the service to return a response immediately. This approach is suitable for scenarios with high real-time requirements, such as real-time data queries. Asynchronous request / response: After sending a request, the client does not need to wait for a response immediately and can continue performing other tasks. After processing the request, the service returns the response to the client through callbacks or other mechanisms. This approach is suitable for time-consuming tasks or tasks with low real-time requirements, such as batch data processing. Subscribe / publish: Clients can subscribe to topics or events of interest, and receive notifications when the service publishes relevant messages. This approach is suitable for event-driven architectures, such as real-time monitoring systems.

[0040] A service can be a business logic processing unit, responsible for executing specific tasks and returning results. Each service provides specific functions, such as data querying, data processing, and device control. Upon startup, a service needs to register with the service bus daemon, providing its own metadata (such as service name, address, and function description). The daemon maintains a service directory, which clients can query to find the services they need. Status monitoring: The service bus daemon periodically monitors the service's running status, such as heartbeat detection and health checks. If a service is found to be unavailable or abnormal, the daemon will take appropriate measures, such as restarting the service or notifying the administrator. The service bus daemon is responsible for monitoring the service's registration and running status to ensure service availability and reliability. The service bus supports synchronous / asynchronous request / response and publish / subscribe modes and includes a shared memory area, a network communication message queue, and the service bus daemon. For multiple processes within the same machine, zero-copy data exchange is performed through the shared memory area; for cross-node process communication, a network channel is built using the network communication message queue; and the service bus daemon performs unified registration, status management, and health monitoring of distributed services.

[0041] This architectural design decouples clients from services, improving the scalability, flexibility, and reliability of the service bus. Clients do not need to know the specific location and implementation details of services; they can access the required services simply through the service bus. Services can also be developed and deployed independently, facilitating system maintenance and upgrades.

[0042] In step S330, in response to determining that the service type of the service call request is a local service, the service processing thread obtains the first data for the service call request based on the local shared memory area, and generates a first return result based on the first data and sends it to the first target node of the service call request.

[0043] The service type indicates the service area associated with the service call request, such as a local service or a cross-node service. A local service refers to a service whose processing primarily relies on local resources and involves little or no interaction with other nodes across the network. In a power load control system, such as a real-time query service for the status of equipment within a local substation, the required data (such as equipment operating parameters and status information) is stored in a local database or shared memory area, and the processing logic is also completed locally, without needing to request large amounts of data or perform complex interactive operations from other remote nodes over the network. The first data can be data closely related to the request, obtained by the service processing thread from the local shared memory area for a service call request of the local service type. This data is essential for completing the local service processing. For example, in a local load adjustment service, the first data may include the current real-time load value of the local area, the power consumption status of each electrical device, and preset load adjustment strategy parameters. The service processing thread uses this data for subsequent calculations and logical processing. The first return result can be the response information generated by the service processing thread based on the obtained first data and after a series of business logic processes for the local service call request. It is a response to the request from the business initiator and includes the result of the request processing. For example, in a local load query service, the first returned result might be the total load value of the current local area, detailed data for each load category, etc.; in a local device control service, the first returned result might be status feedback on whether the device successfully executed the control command. The first target node can be the object node that receives the first returned result, such as the node where the business initiator that initiated the local service call request is located. In a power load control system, this could be a workstation in the power grid dispatch center, a monitoring terminal of an industrial user, etc. The service processing thread accurately sends the generated first returned result to the first target node to meet the business initiator's need to obtain the service processing result, enabling it to make subsequent decisions or operations based on the result.

[0044] Differentiated processing can be implemented based on the service type of the request: If it is determined to be a local service, the service processing thread will retrieve relevant data using the local shared memory area. The shared memory area can be a data storage and sharing region, from which the local service can directly and quickly read the required data, generate a return result based on this data, and send it to the corresponding first target node; if it is determined to be a cross-node service, the service processing thread will send the result to the second target node after generating the result, using a network communication message queue. The network communication message queue can guarantee the reliability and order of messages during network transmission, ensuring that cross-node services can complete the interaction accurately. That is, in the hybrid communication architecture, the service processing thread dynamically adapts the processing strategy according to the request type: for local services, data is quickly read directly through the shared memory area, reducing I / O overhead; for cross-node services, reliable network transmission is achieved through a message queue, ensuring data consistency and order. This design enables the system to efficiently handle high-concurrency, multi-type load control requests, supporting real-time power grid scheduling and collaborative optimization.

[0045] like Figure 5 As shown, Figure 5 A schematic diagram of a shared memory area according to an embodiment of this disclosure is shown. Based on the data characteristics of power grid services, the shared memory area facilitates data exchange between multiple processes within the local machine, achieving zero-copy transmission and stabilizing latency at the microsecond level. Employing lock-free design and zero-copy technology, it enhances concurrent processing capabilities through pre-allocated memory pools and atomic operations. Thus, by utilizing the local shared memory area to acquire data, the time and complexity of data reading are reduced, significantly improving the response speed of local services. This enables rapid fulfillment of the needs of local service initiators, enhancing the real-time performance and efficiency of power load control in local scenarios.

[0046] In some embodiments, method 300 further includes: Based on the data characteristics of the power grid business data, the power grid business data is stored in a shared memory area; wherein, in response to determining that the data characteristic is a first type of characteristic, the power grid business data is stored in a fixed memory area; in response to determining that the data characteristic is a second type of characteristic, the power grid business data is stored in a dynamic memory area.

[0047] Firstly, the shared memory pool partitioning strategy can be determined based on data characteristics such as the volume of measurement data and the frequency of control commands in power grid operations. Fixed partitioning is used for small-volume, high-frequency data, while dynamic partitioning is used for large-capacity data. A zero-copy transmission mechanism is implemented, and a global memory pool is designed. Processes share data by mapping to the same memory region. Lock-free synchronization uses atomic operations or CAS mechanisms to avoid thread blocking. A signaling notification scheme is developed, using an event-driven model to replace traditional polling. When a producer completes data writing, it triggers real-time signaling to notify the consumer, ensuring timely data processing and reducing signaling latency.

[0048] In some embodiments, generating a first return result based on the first data and sending it to the first target node of the service call request includes: In response to detecting the service call request, the data producer stores the first data in the fixed memory area and generates a first return result indicating that the first data storage was successful; the first target node, in response to receiving the first return result, reads the first data based on the fixed memory area indicated by the first return result. or, The service processing thread processes the first data based on the data service corresponding to the service call request, generates the first return result, and sends the first return result to the first target node.

[0049] Specifically, for local service call requests, a first return result is generated and sent to the first target node based on the first data. In some embodiments, when the data producer detects that the first data has been stored in a fixed memory area, a first return result indicating successful storage is directly generated. The first target node then reads the data from the fixed memory area accordingly, simplifying the processing flow and ensuring efficient feedback and acquisition of the data readiness status. In other embodiments, the service processing thread processes the first data using the corresponding data service before generating and sending the first return result, meeting the needs of business scenarios requiring data processing. This allows for flexible adaptation to different business requirements, improving the efficiency and adaptability of local service processing, and ensuring that the first target node can obtain the required data or processing results in a timely and accurate manner.

[0050] In step S340, in response to determining that the service type of the service call request is a cross-node service, the service processing thread generates a second return result for the service call request and sends it to the second target node of the service call request based on the network communication message queue.

[0051] Cross-node services refer to service invocation requests where the business processing involves crossing different network nodes. These nodes may be geographically distributed, possessing their own independent computing resources, storage resources, and business functions. For example, a large power group may have multiple regional dispatch centers in different regions. When coordinated adjustment of power loads in multiple regions is required, a load adjustment request initiated by one regional dispatch center needs to interact with dispatch centers in other regions. This type of service involving multi-node collaborative processing is a cross-node service. Cross-node services typically require data transmission and communication over the network to achieve information sharing and business collaboration between different nodes. The second return result can be the response information generated by the service processing thread after a series of processing steps for a cross-node service type service invocation request. Unlike the first return result of a local service, the second return result may contain richer information due to the interaction of multiple nodes and complex data processing logic involved in cross-node services. For example, in a cross-regional power load coordinated adjustment service, the second return result may not only include the adjusted load value but also the adjusted status information of each node, any abnormal situations that occurred during the adjustment process, and handling suggestions. The purpose of the second return result is to provide feedback on the processing result of the cross-node service request to the second target node, so that the second target node can make subsequent decisions or operations based on the result. The second target node can be the object node receiving the second return result, such as the node where the business initiator that initiated the cross-node service call request is located, or other nodes related to the cross-node service that need to obtain the processing result. In a power load control system, the second target node might be a dispatch center in another region, a monitoring terminal of a higher-level management department, or other business systems related to power load control. For example, in a cross-regional power load coordinated adjustment service, the regional dispatch center that initiated the request is the business initiator, while other regional dispatch centers participating in the coordinated adjustment and the monitoring terminal of the higher-level management department could be second target nodes, needing to receive the second return result to understand the adjustment status and results.

[0052] Network communication message queues are middleware used for storing and forwarding messages in network communication. In cross-node services, communication between different nodes may face problems such as network latency, data loss, and message out-of-order delivery. Network communication message queues can effectively solve these problems. For example, message storage: When a service processing thread generates a second return result, it sends it to the network communication message queue. The message queue stores the message, ensuring that it is not lost due to network problems or temporary unavailability of the recipient. Asynchronous communication: Message queues support asynchronous communication modes. The sender and receiver do not need to be online simultaneously. The sender can continue to perform other tasks after sending the message to the queue, and the receiver can retrieve the message from the queue for processing at an appropriate time, improving the system's concurrency and response speed. Message order guarantee: Network communication message queues can guarantee that messages are stored and forwarded in the order they are sent, ensuring that the receiver can process messages in the correct order and avoiding data inconsistencies or business logic errors caused by message out-of-order delivery. Load balancing: When multiple receivers retrieve messages from the message queue at the same time, the message queue can distribute the messages evenly to each receiver according to a certain strategy to achieve load balancing and prevent a receiver from becoming a system bottleneck due to processing too many messages.

[0053] By using network communication message queues, problems such as message loss and out-of-order delivery that may occur during cross-network transmission are effectively solved. This ensures that the results of cross-node services can be accurately and stably sent to the target node, enhancing the reliability and stability of the system in a distributed environment. This facilitates large-scale, multi-node collaborative control of power loads. The overall solution can better adapt to different types of needs in power load control services, improving the overall performance and business processing capabilities of the system.

[0054] like Figure 6 As shown, Figure 6 A schematic diagram of cross-node process communication according to an embodiment of this disclosure is shown. For cross-node process communication, a high-performance network communication message queue is used to construct the network channel, achieving an end-to-end response time in milliseconds. For real-time power grid control command transmission scenarios, an efficient addressing and low-latency path for cross-node services is established, and a distributed resolution mechanism based on service identifiers is designed to map logical service identifiers to the optimal physical node address. Through lightweight signaling interaction, the construction of the end-to-end transmission path is completed in microseconds, avoiding the overhead of traditional protocol stacks.

[0055] In some embodiments, the service processing thread generates a second return result for the service call request and sends it to the second target node of the service call request based on a network communication message queue, including: Based on the service metadata identifier indicated by the service call request, the optimal path from the service initiator to the second target node is determined; Based on the optimal path, the second data of the service initiator is sent to the second target node as the second return result via the network communication message queue.

[0056] This involves establishing an efficient addressing and low-latency path for cross-node service network communication message queues, designing a distributed resolution mechanism based on service identifiers to map logical service identifiers to optimal physical node addresses, and constructing end-to-end transmission paths within microseconds through lightweight signaling interaction. It also implements intelligent network routing and addressing methods, where service discovery is based on metadata identifiers such as service ID and version, and optimal path selection is achieved through lightweight signaling interaction. The optimal path is the path with the minimum sum of latency and cost among all possible paths; a balance is found by adding latency and cost. The routing algorithm can be expressed as:

[0057] For scenarios involving the transmission of real-time control commands to the power grid, the frequency of shortest path node status updates is adjusted, and the channel stability mechanism is optimized to prevent data loss caused by path interruptions and ensure the reliable delivery of critical commands.

[0058] In some embodiments, method 300 further includes: Based on the priority of the service call request's service type, corresponding memory resources, bandwidth resources, and computing resources are allocated; wherein, the service type of real-time control instructions has the highest priority, the service type of measurement data has a lower priority than the real-time control instructions, and the service type of historical data has a lower priority than the measurement data.

[0059] Specifically, memory, bandwidth, and computing resources are allocated rationally based on the priority of the service call request type. Service types are categorized into real-time control commands, measurement data, and historical data, with priority decreasing sequentially. Real-time control commands have the highest priority, receiving ample resources to ensure their rapid and accurate execution, thus meeting the real-time control needs of the power system. Measurement data has the next highest priority, receiving relatively matching resources to support timely data acquisition and transmission. Historical data has the lowest priority, being allocated resources relatively later in the allocation process. This differentiated resource allocation strategy effectively ensures the smooth operation of high-priority services, improves the overall performance and response speed of the power load control system, and enables more scientific and efficient utilization of system resources.

[0060] Specifically, the server dynamically and configurably allocates memory, bandwidth, and computing resources based on the priority of the service type. The core principle is that higher-priority service types receive more resource quotas, higher scheduling priority, and lower queuing latency during resource contention. The specific allocation strategy is as follows: 1. Computational resource allocation (primarily reflected in thread / CPU time slices) Thread pool isolation and quotas: The server configures independent or dedicated thread pools with minimum resource guarantees for different priority business types. For example, a high-priority thread pool is set up for the "real-time remote control command" service, with its threads accounting for 40% of the total computing threads on the server, and these threads themselves can be set to higher scheduling priority in the operating system kernel scheduling.

[0061] Dynamic thread allocation: When high-priority business requests surge, the system temporarily borrows threads from the thread pool serving low-priority business (such as "historical data synchronization") and transfers them to the high-priority thread pool to ensure immediate response to real-time commands. The thread resources are then returned after the peak period.

[0062] Preemption handling: For tasks already in execution, if the highest priority request arrives, lower priority tasks that can be safely interrupted are temporarily suspended to release computing resources. Computing resources are then used for higher priority services.

[0063] 2. Memory resource allocation Request buffer pre-allocation: Set up independent request receive buffers for each service type. The buffer size for high-priority services is fixed and the memory is pre-locked to prevent it from being occupied by other processes, ensuring that there is still memory to receive new instructions under extreme load.

[0064] Memory cache priority: For frequently used data such as telemetry and teleindication, a higher priority is set for frequently used data in the server-side memory cache. High-priority cached data is less likely to be evicted and stays in memory for a longer time.

[0065] Memory protection during processing: Allocate independent, protected memory workspaces for service instances that handle high-priority requests to ensure that their execution process is not forcibly terminated or swapped due to overall system memory shortage, thereby guaranteeing the processing latency of high-priority services.

[0066] 3. Bandwidth resource allocation (network I / O resources) Bandwidth reservation and rate limiting: A dedicated minimum guaranteed bandwidth is reserved for the "real-time remote control command" service to ensure its smooth transmission path. Simultaneously, a bandwidth cap is set for the "historical data synchronization" service to prevent its large data volume transmissions from crowding out the bandwidth of critical services.

[0067] Connection management: Limit the maximum number of concurrent connections initiated by low-priority services (such as historical data synchronization) to the server, so that more network connection resources can be reserved for high-priority services.

[0068] For example, when the service bus receives multiple service requests simultaneously, the resource allocation and scheduling process is as follows: Request Classification and Tagging: Requests are parsed according to the order in which they arrive and identified as categories such as "Real-time Remote Control Command (High Priority)" or "Historical Data Synchronization (Low Priority)" based on the service type variable in their message headers.

[0069] Entry into Priority Queues: Based on the pre-configured priority levels for various service requests, requests are added to the corresponding priority input queues. High-priority queues use shorter queue lengths. When a high-priority queue is full, the oldest requests in the low-priority queues are discarded to make way for new high-priority requests.

[0070] Resource coordination and allocation: The core scheduler dynamically calculates the resource allocation ratio for each business type in the current scheduling cycle based on the backlog of each priority queue. The core principle is to allocate the highest proportion to high priority queues, and the proportion decreases step by step as the queue priority decreases.

[0071] Monitoring and Dynamic Adjustment: The system monitors the processing latency, success rate, and resource utilization of each service type in real time. If the latency of a high-priority service approaches a pre-set latency threshold, an elastic expansion mechanism is triggered, allocating thread quotas and bandwidth from low-priority services to high-priority services until the metrics return to normal, at which point the corresponding resources are returned to the low-priority services.

[0072] In some embodiments, method 300 further includes: In response to the service call request meeting preset conditions, a hybrid transmission is performed based on the shared memory area and the network communication message queue.

[0073] A fusion control module is added between the shared memory area and the network communication message queue to achieve real-time synchronization of memory channel status and routing path information. A hybrid transmission mode is implemented, with a unified communication interface designed to support automatic transmission mode selection. When sending messages, local communication prioritizes shared memory, while cross-node communication switches to network transmission to ensure low latency and high throughput. Priority scheduling rules are formulated based on the type of power grid service. Real-time power load control commands have the highest priority, measurement data has medium priority, and historical data has low priority. A resource allocation module, combined with priority settings, is used to allocate memory, bandwidth, and computing resources for the services.

[0074] Specifically, the hybrid transmission based on the shared memory area and the network communication message queue mainly involves the dynamic selection of communication paths and service nodes to form an optimal service call chain that balances efficiency, reliability, and load balancing. This process comprehensively considers node location (same machine / cross machine), node status (master / standby machine, load), and the priority of the requested service.

[0075] Assume the system has the following critical service nodes: Node A (data acquisition node): deployed on the front-end machine, the main machine (A_M) and the backup machine (A_S).

[0076] Node B (Real-time Computing Node): Deployed on the computing server, the main machine (B_M) and the standby machine (B_S).

[0077] Node C (Real-time Database Node): Deployed on the core database server, the primary (C_M) and the standby (C_S).

[0078] Node D (historical storage node): Deployed on the historical data server.

[0079] For example, when processing high-priority telemetry data in real time: Request Initiation: The business unit requests the latest bus voltage and performs over-limit judgment (high priority business).

[0080] Service orchestration: The service bus determines which node A (to obtain raw data) and node B (to perform calculations) need to be called.

[0081] Node and path selection: Scenario 1: If A_M and B_M are deployed on the same physical server, the service bus will prioritize scheduling requests to transfer data between A_M and B_M through the shared memory area, achieving microsecond-level latency.

[0082] Scenario 2: If A_M and B_M are not on the same server, but A_M and B_S are on the same machine, and B_S is in good condition (low load, timely data synchronization), the service bus calls A_M (master) and B_S (standby) to communicate through shared memory in the same machine environment. This path is faster than cross-machine network communication (A_M -> B_M).

[0083] Scenario 3: If all primary and backup machines of A and B are different machines, then a network communication message queue is used, and the message is marked with the highest priority to enjoy bandwidth resource guarantee.

[0084] For example, when archiving low-priority historical data: Request Initiation: The background analysis task requests to synchronize all remote signaling data from the past 24 hours (low-priority business).

[0085] Service orchestration: Node C (reading the real-time database) and Node D (writing to the historical database) need to be invoked.

[0086] Node and Path Selection: Due to the large volume of historical synchronization data and low real-time requirements, the service bus proactively chooses to transmit via network communication message queues, even if C_M and D_M are on the same machine. This selection aims to avoid large data copies consuming valuable shared memory and prevent them from interfering with high-priority real-time communication. During network transmission, the data stream for this service will be marked as low priority and may be rate-limited or allowed delays during queue scheduling.

[0087] The hybrid transmission decision-making process combining priority scheduling proposed in this disclosure may include: The "hybrid transport scheduler" embedded in the service bus executes the following logic when determining the transport method, which is deeply coupled with service priority: Request parsing and priority mapping: After receiving a service call request, first parse its service type ("real-time remote control command (high priority)" or "historical data synchronization (low priority)") and map it to the preset transmission priority label (such as P0-urgent, P1-high, P2-medium, P3-low).

[0088] Node discovery and status assessment: The scheduler queries the service registry to obtain a list of all nodes that can provide the target service (including their host / standby identifier, deployed physical machine address, current load, health status, network latency with upstream nodes, etc.).

[0089] Dynamic path decision (core): The scheduler calculates a weighted score for each possible "service node combination + communication path" based on business priorities. The score weights are configured according to: For high-priority (P0, P1) requests: Speed ​​is given extremely high weight: Prioritize node combinations that can use shared memory for communication (i.e., nodes on the same machine). If nodes on the same machine cannot communicate, select the path with the best network quality (lowest latency and lowest packet loss rate).

[0090] High reliability weight: Even if the primary machine is available, if the overall path score (considering load) of the backup machine is higher, the backup machine can be preferred and services can be provided through shared memory.

[0091] Low resource consumption considerations: Allows for more shared memory bandwidth to be used to ensure its speed.

[0092] For low-priority (P2, P3) requests: High system stability weight: Network communication message queues are used by default to avoid blocking shared memory.

[0093] High cost / load weight: Actively select standby nodes with lower load, even if cross-machine network communication is required, slightly higher latency is acceptable.

[0094] Preemption or delay is possible: When system resources are scarce, network messages may be throttled or wait in a queue.

[0095] Perform mixed transmission: The scheduler determines the optimal combination of "target node" and "transmission method". A single service call chain may contain multiple communication segments, each of which may use a hybrid method.

[0096] Example path: Business side -> (Network message) -> Node A host -> (Shared memory) -> Node B standby host on the same machine -> (Network message, high priority) -> Node C host.

[0097] Failover and dynamic adjustment: If a node or communication link fails during transmission, the scheduler will immediately trigger rerouting based on the priority of the original request.

[0098] High-priority request: Attempt to switch to another local node (via shared memory) or the optimal network path within milliseconds.

[0099] Low-priority requests may be retried within seconds or placed in a queue to wait for recovery.

[0100] In some embodiments, the service processing thread also performs at least one of the following: Register service information based on the service call request; the registered service information includes at least one of the service name, service node address, service listening port, and the application in which the service is located. Record the arrival time, requested data volume, response duration, and returned result size of the service request; Track the processing progress of the service call request; The network status of the associated node that receives the service call request is maintained, and the validity of the network status is maintained based on a heartbeat mechanism.

[0101] This involves unified registration and status management of distributed services required for power load control. A distributed service discovery module is designed so that when the service registry receives a call from a client initiating a service request, it creates an independent processing thread to execute the corresponding task. Service registration information includes the service name, service node IP, service listening port, and the application where the service resides. Based on the request protocol, the service first identifies whether the caller is in a local environment or a cross-node network. The service records the arrival time of the request, tracks the processing progress throughout, and tracks the request data volume, response time, and return result size. After distributed service registration, business nodes automatically report their network status and maintain node status validity through a heartbeat mechanism.

[0102] The system dynamically maintains service metadata and topology information through node self-registration and proactive health probe mechanisms. It monitors and manages the registration service to ensure stable operation. A service query interface is provided to enable business applications to quickly resolve the network location of target communication objects, ensuring optimal node selection based on business needs and improving target location efficiency.

[0103] like Figure 4 As shown, the service bus daemon can monitor and manage registered services, ensuring their stable operation. It provides unified registration and status management for distributed services required in power load control. Through node self-registration and proactive health probe mechanisms, it dynamically maintains service metadata and topology information, enabling automated registration, discovery, and lifecycle management of service instances.

[0104] As can be seen, this disclosure solves the problems of high communication latency, low transmission efficiency, and complex service management in traditional systems by constructing a service bus that integrates a shared memory area and a network communication message queue. For local process communication, a zero-copy and lock-free shared memory area is used to achieve microsecond-level latency; for cross-node communication, a high-performance message queue is used and a low-latency path is established. Simultaneously, a unified service registration, discovery, and lifecycle management are achieved through a service bus daemon, and automatic scheduling of hybrid transmission modes is implemented based on service priorities. This disclosure combines high transmission performance with reliable scalability, effectively meeting the dual requirements of real-time performance and stability for power load control systems.

[0105] It should be noted that the method of this embodiment can be executed by a single device, such as a computer or server. The method of this embodiment can also be applied to a distributed scenario, where multiple devices cooperate to complete the task. In such a distributed scenario, one of these devices may execute only one or more steps of the method of this embodiment, and the multiple devices will work together to generate video to complete the method described.

[0106] It should be noted that the above description describes some embodiments of this disclosure. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in a different order than that shown in the above embodiments and still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0107] Based on the same technical concept, corresponding to any of the above embodiments, this disclosure also provides a power load control device based on a hybrid communication architecture, see [link to relevant documentation]. Figure 7 The power load control device based on a hybrid communication architecture includes: The receiving module is used to receive service call requests from the business initiator. The thread module is used to create a service processing thread for the service call request; and In response to determining that the service type of the service call request is a local service, the service processing thread obtains the first data for the service call request based on the local shared memory area, and generates a first return result based on the first data and sends it to the first target node of the service call request. In response to determining that the service type of the service call request is a cross-node service, the service processing thread generates a second return result for the service call request and sends it to the second target node of the service call request based on the network communication message queue.

[0108] For ease of description, the above apparatus is described in terms of its functions, divided into various modules. Of course, in implementing this disclosure, the functions of each module can be implemented in one or more software and / or hardware.

[0109] The apparatus of the above embodiments is used to implement the corresponding power load control method based on the hybrid communication architecture in any of the foregoing embodiments, and has the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0110] Based on the same technical concept, corresponding to the methods of any of the above embodiments, this disclosure also provides a non-transitory computer-readable storage medium storing computer instructions for causing the computer to execute the power load control method based on a hybrid communication architecture as described in any of the above embodiments.

[0111] The computer-readable medium of this embodiment includes permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0112] The computer instructions stored in the storage medium of the above embodiments are used to cause the computer to execute the power load control method based on the hybrid communication architecture as described in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0113] Those skilled in the art should understand that the discussion of any of the above embodiments is merely exemplary and is not intended to imply that the scope of this disclosure (including the claims) is limited to these examples; within the framework of this disclosure, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of the embodiments of this disclosure as described above, which are not provided in detail for the sake of brevity.

[0114] Additionally, to simplify the description and discussion, and to avoid obscuring the embodiments of this disclosure, the provided drawings may or may not show well-known power / ground connections to integrated circuit (IC) chips and other components. Furthermore, the apparatus may be shown in block diagram form to avoid obscuring the embodiments of this disclosure, and this also takes into account the fact that the details of implementation of these block diagram apparatuses are highly dependent on the platform on which the embodiments of this disclosure will be implemented (i.e., these details should be fully understood by those skilled in the art). While specific details (e.g., circuits) have been set forth to describe exemplary embodiments of this disclosure, it will be apparent to those skilled in the art that the embodiments of this disclosure can be implemented without these specific details or with variations thereof. Therefore, these descriptions should be considered illustrative rather than restrictive.

[0115] Although this disclosure has been described in conjunction with specific embodiments thereof, many substitutions, modifications, and variations of these embodiments will be apparent to those skilled in the art from the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may be used with the embodiments discussed.

[0116] This disclosure is intended to cover all such substitutions, modifications, and variations that fall within the broad scope of the appended claims. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A power load control method based on a hybrid communication architecture, comprising: Receive service call requests from the business initiator; Create a service processing thread for the service call request; In response to determining that the service type of the service call request is a local service, the service processing thread obtains the first data for the service call request based on the local shared memory area, and generates a first return result based on the first data and sends it to the first target node of the service call request. In response to determining that the service type of the service call request is a cross-node service, the service processing thread generates a second return result for the service call request and sends it to the second target node of the service call request based on the network communication message queue.

2. The method according to claim 1, further comprising: Based on the data characteristics of the power grid business data, the power grid business data is stored in a shared memory area; wherein, in response to determining that the data characteristic is a first type of characteristic, the power grid business data is stored in a fixed memory area; in response to determining that the data characteristic is a second type of characteristic, the power grid business data is stored in a dynamic memory area.

3. The method according to claim 1, wherein, Based on the first data, a first return result is generated and sent to the first target node of the service call request, including: In response to detecting the service call request, the data producer stores the first data in the fixed memory area and generates a first return result indicating that the first data storage was successful; the first target node, in response to receiving the first return result, reads the first data based on the fixed memory area indicated by the first return result. or, The service processing thread processes the first data based on the data service corresponding to the service call request, generates the first return result, and sends the first return result to the first target node.

4. The method according to claim 1, wherein, The service processing thread generates a second return result for the service call request and sends it to the second target node of the service call request based on a network communication message queue, including: Based on the service metadata identifier indicated by the service call request, the optimal path from the service initiator to the second target node is determined; Based on the optimal path, the second data of the service initiator is sent to the second target node as the second return result via the network communication message queue.

5. The method according to claim 1, further comprising: Based on the priority of the service call request's service type, corresponding memory resources, bandwidth resources, and computing resources are allocated; wherein, the service type of real-time control instructions has the highest priority, the service type of measurement data has a lower priority than the real-time control instructions, and the service type of historical data has a lower priority than the measurement data.

6. The method according to claim 1, further comprising: In response to the service call request meeting preset conditions, a hybrid transmission is performed based on the shared memory area and the network communication message queue.

7. The method according to claim 1, wherein the service processing thread further performs at least one of the following: Register service information based on the service call request; the registered service information includes at least one of the service name, service node address, service listening port, and the application in which the service is located. Record the arrival time, requested data volume, response duration, and returned result size of the service request; Track the processing progress of the service call request; The network status of the associated node that receives the service call request is maintained, and the validity of the network status is maintained based on a heartbeat mechanism.

8. A power load control device based on a hybrid communication architecture, comprising: The receiving module is used to receive service call requests from the business initiator. The thread module is used to create service processing threads for the service call requests. as well as In response to determining that the service type of the service call request is a local service, the service processing thread obtains the first data for the service call request based on the local shared memory area, and generates a first return result based on the first data and sends it to the first target node of the service call request. In response to determining that the service type of the service call request is a cross-node service, the service processing thread generates a second return result for the service call request and sends it to the second target node of the service call request based on the network communication message queue.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the method as claimed in any one of claims 1 to 7.

10. A non-transitory computer-readable storage medium storing computer instructions for causing a computer to perform the method of any one of claims 1 to 7.

Images