Low-delay micro-grid data transmission proxy method

Abstract

The invention relates to the technical field of micro-grids, and discloses a low-delay micro-grid data transmission proxy method, which comprises the following steps of: A, constructing an object model of equipment based on attributes, events and behaviors of the micro-grid equipment; b, preprocessing equipment data: processing the data before sending the data according to the event definition of the object model; c, data transmission: transmitting the data by adopting a communication protocol; and D, message proxy: performing proxy and forwarding on the message by adopting a low-delay message proxy algorithm. The attributes of the micro-grid equipment comprise parameters and state data of the micro-grid equipment in the operation process, including identification, name, definition, constraint, type and description. According to the micro-grid data processing method and system, the total delay of data transmission can be reduced by preprocessing data transmission, so that the data transmission efficiency can be greatly improved, the micro-grid data processing efficiency can also be greatly improved, and changes and requirements in a micro-grid can be quickly responded.

Description

Technical Field

[0001] The present invention relates to the technical field related to microgrids, and in particular to a low-latency microgrid data transmission proxy method. Background Art

[0002] With the development of microgrid technology, data transmission performance in microgrids is crucial to the overall operating efficiency of the system. Existing low-latency data transmission technologies mainly focus on optimizing communication architecture to improve the communication performance and security between components in microgrids. In order to ensure real-time control and data exchange of microgrids, it is particularly important to adopt advanced control methods and stable communication strategies.

[0003] In microgrids based on the Internet of Things (IoT), especially in independently operated microgrid systems, the importance of low-latency secure communication architecture is even more prominent. In these systems, the optimization of communication architecture needs to ensure low latency of data transmission while also solving security issues in data transmission.

[0004] However, traditional security mechanisms (such as encryption, authentication, etc.) often inadvertently introduce additional delays, and various control operations in microgrids (such as load regulation, energy distribution, equipment start and stop, etc.) have extremely high real-time requirements. Excessive delay will cause control commands or data to fail to reach the target device in time during the transmission process, which may cause the system to fail to respond in time, thereby damaging the equipment or causing power outages. Therefore, minimizing communication delays has become an issue that needs to be urgently addressed in this field. Summary of the invention

[0005] In view of the shortcomings of the prior art, the present invention provides a low-latency microgrid data transmission agent method, which solves the problem in the prior art that the high delay of microgrid equipment may cause the control command or data to fail to reach the target device in time during the transmission process, which may cause the system to fail to respond in time, thereby damaging the equipment or causing power outages.

[0006] To achieve the above objectives, the present invention is implemented through the following technical solutions: a low-latency microgrid data transmission agent method, comprising the following steps:

[0007] A. Physical model of devices based on the properties, events and behaviors of microgrid devices;

[0008] B. Device data preprocessing: According to the event definition of the object model, the data is processed before it is sent;

[0009] C. Data transmission: Use communication protocol to transmit data;

[0010] D. Message proxy: Use low-latency message proxy algorithm to proxy and forward messages.

[0011] Preferably, the attributes of the microgrid device include parameters and status data of the microgrid device during operation, including identification, name, definition, constraint, type and description.

[0012] Preferably, the attributes of the microgrid device support two categories: read-write and read-only. Read-write means that the attribute can be reported from the device to the platform and can also be controlled from the platform. Read-only means that the attribute is only reported from the device to the platform.

[0013] Preferably, the events of the microgrid device include data initiated by the device during operation that needs to be perceived by the user business system, including three event types: information, alarm, and fault. Information is a reporting event generated by the device in normal business processing, an alarm is a reporting event triggered by excessively high values ​​of certain attributes of the device under normal operation, and a fault is a reporting event triggered by the device's inability to operate normally.

[0014] Preferably, the behavior of the microgrid device includes a callable method provided by the device for the business system to request and receive a response.

[0015] Preferably, the communication protocols include MQTT, WebSocket and HTTP.

[0016] Preferably, the messages forwarded in the message proxy are divided into event messages and behavior messages, the event messages include basic information reporting, alarm information reporting, and fault message reporting, and the behavior messages are responsible for downlink control.

[0017] Preferably, the message agent implements the steps as follows:

[0018] (a) Priority Assignment

[0019] Each arriving message is assigned a static priority, which remains unchanged throughout the life cycle of the message. The forwarding priorities of the event message and behavior message are, from high to low, fault message, alarm message, behavior message, and basic information. After the message arrives, it enters the cache queue first;

[0020] (b) Message preemption

[0021] In an environment where multiple messages arrive, if a high-priority message becomes ready, that is, a new message arrives, the high-priority message will preempt the forwarding of the low-priority message being forwarded, and the preempted low-priority message will be cached until all higher-priority messages are forwarded;

[0022] (c) Message Scheduling

[0023] The scheduler determines the next message to be forwarded according to the priority of the message and the ready time of the message, ensuring that the message with the highest priority is processed first.

[0024] Preferably, the low-latency message proxy algorithm includes four parts:

[0025] (1) Symbol definition:

[0026] Let M represent the set of messages;

[0027] Each message m ∈ M has a fixed priority p(m), where p:M→N is the priority function;

[0028] Q(t) represents the cache queue at time t, where

[0029] status(m,t) indicates the status of message m at time t, which can be set to "ready" or "not ready";

[0030] C(t) represents the message being forwarded at time t;

[0031] (2) Priority allocation:

[0032] The priority p(m) is determined in advance according to the message type and remains unchanged during the life cycle of the message;

[0033] (3) Message preemption:

[0034] Define the preemption function preempt(m, m′, t) as:

[0035]

[0036] If preempt(m,C(t),t)=1, message m preempts C(t), and C(t) is placed in Q(t);

[0037] (4) Message Scheduling:

[0038] The scheduling function schedule(Q(t)t) selects the ready message m with the highest priority in Q(t) as C(t+1):

[0039]

[0040] Message m is removed from Q(t) and forwarding begins.

[0041] Preferably, when the network state is unstable and packet loss occurs, the low-latency message proxy algorithm preferentially uses a communication protocol with a confirmation mechanism for data transmission, including:

[0042] Adopt the quality assurance level mechanism in the MQTT protocol to ensure reliable message delivery in unstable network conditions;

[0043] The unconfirmed critical messages are automatically resent through the message resending mechanism until successful confirmation feedback is received.

[0044] The present invention provides a low-latency microgrid data transmission agent method, which has the following beneficial effects:

[0045] 1. The present invention can reduce the overall delay of data transmission by performing preprocessing before data transmission, thereby greatly improving the efficiency of data transmission, and the processing efficiency of microgrid data will also be greatly improved, which is conducive to quickly responding to changes and demands within the microgrid.

[0046] 2. By introducing real-time data processing and priority queues, the present invention can give priority to the data of key operations and emergency responses, so that the system can respond to emergencies more quickly, ensure the stable operation of the microgrid in a highly automated environment, and ensure that key messages are processed in a timely manner. This not only improves the efficiency of data processing, but also improves the reliability of the entire microgrid when facing complex and critical tasks. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] Figure 1 It is a block diagram of the physical model connection of the present invention;

[0048] Figure 2 This is a message agent connection block diagram of the present invention. DETAILED DESCRIPTION

[0049] The following will be combined with the drawings in the specification of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0050] Embodiment 1:

[0051] Please see attached Figure 1 -Attached Figure 2 , an embodiment of the present invention provides a low-latency microgrid data transmission agent method, comprising the following steps:

[0052] A. Physical model of devices based on the properties, events and behaviors of microgrid devices;

[0053] B. Device data preprocessing: According to the event definition of the object model, the data is processed before it is sent;

[0054] C. Data transmission: Use communication protocol to transmit data;

[0055] D. Message proxy: Use low-latency message proxy algorithm to proxy and forward messages.

[0056] In A above, the physical model of the device is constructed based on the properties, events and behaviors of the microgrid device: In the microgrid system, the physical model is used to systematically describe the core characteristics of the device and its interactive behavior. The properties of the device include identifiers, names, types, constraints, operating parameters and status data, etc., which comprehensively define the performance of the device in different operating scenarios. The event part covers various types of data and operations triggered by the device during operation, including information reporting in routine business, alarms in abnormal states, and equipment failure events. These events allow the system to monitor the operating status of the device in real time and take corresponding measures in time. The behavior part defines the callable methods provided by the device, supports two-way interaction between the business system and the device, and can realize device control and status feedback by calling specific functions on the device side, thereby forming a close linkage between the device and the platform.

[0057] In B above, device data preprocessing: before the data is sent, preprocessing is performed according to the events defined in the physical model. This preprocessing step aims to reduce data redundancy, optimize the data transmission format, and reduce network bandwidth occupancy by filtering and compressing the data generated by the device. Data preprocessing can classify and prioritize different types of event data so that critical event data (such as fault and alarm information) can be prioritized and transmitted quickly. This step also reduces the system's parsing pressure at the data receiving end, avoids unnecessary format conversion and secondary processing, thereby improving the overall transmission efficiency and system response speed, and ensuring that data in the microgrid can be quickly communicated and processed.

[0058] In the above C, data transmission: after completing data preprocessing, the data is transmitted using an efficient communication protocol suitable for the microgrid environment. These communication protocols, such as MQTT, WebSocket or HTTP, are designed for low power consumption, low bandwidth and unstable network environments, and can work stably and efficiently in microgrids. The MQTT protocol, with its lightweight and confirmation mechanism, ensures that data can be reliably transmitted and received in the case of unstable network or packet loss. WebSocket is suitable for scenarios that require two-way real-time communication, ensuring continuous connection between microgrid equipment and the control center. The selection and adaptation of this protocol ensures that the system can dynamically adjust the transmission mode according to the network status to maintain the continuity and stability of data transmission.

[0059] In the above D, message agent: the message agent is the core link in data transmission. It adopts a low-latency message agent algorithm to efficiently forward and process data. The algorithm ensures that the system can give priority to critical data through three key mechanisms: priority allocation, preemptive message forwarding and message scheduling. First, each message is assigned a static priority according to its importance. The priority remains unchanged throughout the life cycle of the message. Key events such as fault messages and alarm messages have the highest priority to ensure that they can be processed first in any case. The preemptive mechanism allows high-priority messages to interrupt the processing of current low-priority messages when they arrive, ensuring that critical data will not be delayed due to the blocking of low-priority tasks. The message scheduler is responsible for dynamic scheduling between multiple messages. According to the priority and ready time of the message, it selects the next message to be forwarded to ensure the real-time responsiveness of the system and the low latency of data transmission. Through this mechanism, the message agent can effectively manage the transmission of a large amount of device data and ensure the stable operation and efficient response of the entire microgrid system.

[0060] The attributes of microgrid devices include parameters and status data of microgrid devices during operation, including identification, name, definition, constraint, type and description.

[0061] The attributes of microgrid equipment include various parameters and status data of the equipment during operation, which constitute the basic description and operation characteristics of the equipment and can fully reflect the status and operating environment of the equipment. Specifically, the attributes include the following:

[0062] Identification: A unique identifier of a device, usually a unique ID or serial number, which is used to distinguish different devices and ensure that each device can be accurately identified in the complex network of the microgrid. The uniqueness of the identifier ensures the reliability and accuracy of data transmission and device control, and avoids device confusion;

[0063] Name: The name of the device is used to simplify the management and operation of the device. It is usually an easy-to-understand descriptive name. It is used together with the identifier to facilitate operators or system software to quickly identify and access the device. The name can be set according to function, location or device type, making device management more intuitive;

[0064] Definition: The definition part is used to describe the function, purpose and role of the equipment in the microgrid system. Through clear definitions, the equipment can be accurately classified and managed. For example, it is a power generation device, energy storage device or load device. The definition is crucial for the normal integration and scheduling of the equipment, because different types of equipment will undertake different tasks in the microgrid;

[0065] Constraints: Constraint attributes define various limiting conditions of the equipment during operation, including power output range, voltage constraints, operating temperature range, startup or shutdown conditions, etc. These constraints ensure that the equipment operates within a specific safety and performance range to avoid equipment damage or microgrid system failure due to exceeding the limiting conditions. Constraints help the system make more intelligent decisions during scheduling and load management;

[0066] Type: The device type indicates the category and nature of the device, such as whether it is a power generation device, energy storage device, distribution device, or load. The type attribute not only determines the functional positioning of the device in the microgrid, but also determines its operation priority and resource allocation in the system. For example, the type of power generation equipment may affect its priority in power supply scheduling, while load equipment needs to be managed according to the demand response strategy;

[0067] Description: The description part provides more detailed information about the device, usually including the technical specifications, manufacturer information, installation location, maintenance history, etc. This information provides necessary background information for the operation and maintenance of the device, and helps operators to quickly locate and repair problems when they occur. The description attribute may also include a link to the device's operating manual or related technical documents, so that operators can obtain support information in a timely manner;

[0068] By defining and managing the above information, microgrid equipment can achieve comprehensive status monitoring and efficient control, so that the microgrid system can maintain stable operation in a complex multi-device environment and respond quickly to emergencies. It can also provide a reliable foundation for the normal operation, maintenance and interaction of equipment with other system components.

[0069] The properties of microgrid devices support two types: read-write and read-only. Read-write means that the property can be reported from the device to the platform, and can also be controlled from the platform. Read-only means that the property is only reported from the device to the platform. The events of microgrid devices include data initiated by the device during operation that needs to be perceived by the user business system, including three types of events: information, alarm, and fault. Information is a report event generated by the device in normal business processing. Alarms are report events triggered by excessively high values ​​of certain attributes of the device under normal operation. Faults are report events triggered by the failure of the device to operate normally. The behavior of microgrid devices includes callable methods provided by the device for business systems to request and receive responses.

[0070] The properties of microgrid devices support two types of operation modes: read-write and read-only. Each operation mode determines the way data interacts between the device and the platform based on the function and security requirements of the device:

[0071] Read-write attributes: Read-write attributes indicate that such data of the device can be reported from the device to the management platform, and the platform can also initiate control instructions to the device. They are usually used in key device control and status management scenarios. For example, the platform can monitor the real-time status of the device by reading the operating status of the device, such as voltage, current, temperature and other parameters, and can also send control commands to the device, such as adjusting the output power or switching the operating mode. The interaction of read-write attributes can not only realize real-time feedback of the device status, but also enable the platform to actively intervene in the operation of the device, thereby optimizing the overall operation strategy of the microgrid. In order to ensure safety and reliability, the control of read-write attributes is usually combined with the permission management mechanism to avoid unauthorized operations from having adverse effects on device operation;

[0072] Read-only attributes: Read-only attributes indicate that this type of data only allows the device to report the status or parameters to the platform, and the platform cannot directly operate and control the device through these attributes. Read-only attributes are usually used to monitor the key parameters of the device or immutable static information, such as device model, installation location, manufacturer information, historical maintenance records, etc. This type of information is crucial to the operation of the device, but for security and consistency reasons, the platform is not allowed to modify it at will. For example, when the temperature or voltage threshold of the device exceeds the limit, the information will be uploaded to the platform through the read-only attribute to trigger the platform's alarm mechanism, but the platform will not directly adjust the operating status of the device through these read-only attributes.

[0073] The event system of microgrid equipment is used to report key status changes to the platform or user business system during equipment operation. According to the importance and scope of impact of the event, the event is usually divided into the following three types:

[0074] Information events: Information events are status reports generated during the normal operation of the equipment. They are part of the system's routine operations. For example, the equipment regularly reports the current voltage, current, power and other data to the platform. As the basic data for system monitoring and optimization, information events usually occur frequently and are the basic data source for the platform to determine whether the equipment is operating within the normal range. They can also be used for historical analysis, fault prediction and equipment performance optimization.

[0075] Alarm events: Alarm events are abnormal status reports triggered when certain attributes of the equipment exceed the set safety threshold during normal operation, such as voltage, current, temperature and other parameters. Such events usually indicate potential risks of the equipment or deviations of operating parameters from the normal range, requiring the platform to issue early warnings or further intervention. For example, when the temperature of the equipment exceeds the safety upper limit, the alarm event will trigger a notification to remind the management personnel to check the operating status of the equipment and take timely measures to adjust the equipment load or start the cooling system. The design of alarm events is to prevent problems before they occur and avoid more serious equipment failures or system interruptions.

[0076] Fault event: A fault event is a serious status report triggered when the device cannot operate normally, usually indicating that the device has been physically or functionally damaged. For example, the failure of key components of the device, power output interruption or communication link disconnection will trigger a fault event. Once a fault event is triggered, the platform will immediately receive a report and take emergency measures, such as switching to backup equipment, reducing system load or performing equipment maintenance. The handling of fault events usually has the highest priority because it directly affects the stability and reliability of the microgrid system and may cause power supply problems on a larger scale.

[0077] The behavior of microgrid devices defines the interaction between the devices and the platform, which is mainly achieved through a series of callable methods. These behaviors are provided by the devices for the platform or user business system to request and receive responses, forming a two-way control and feedback mechanism, in which:

[0078] Behavior call: The behavior of a device is usually a specific operation request initiated by the business system or platform, such as changing the operating state of the device, adjusting the output power, or performing device diagnosis. The behavior call is usually synchronous or asynchronous, depending on the complexity of the device and the requirements of the system. In the synchronous scenario, the platform can immediately obtain the execution results of the device, which is suitable for time-sensitive operations, such as shutting down the load or switching the power supply. In the asynchronous scenario, the device may require a certain amount of processing time to complete the operation. The platform can receive a notification or result of the processing completion later, such as returning a diagnostic report after completing a complete device health check.

[0079] Response mechanism: After the device executes the behavior request initiated by the business system, it will feed back the processing results to the platform. These results can be confirmation messages of successful operations or analysis of the reasons for failed operations, such as device overload, insufficient resources, etc. Through this feedback mechanism, the platform can verify the operation of the device to ensure that the system as a whole is in a controllable state. The definition of behavior and the response mechanism are the core of the interaction between the device and the platform, ensuring that the microgrid system can respond to operational requirements efficiently and flexibly during operation, and realize dynamic adjustment and intelligent management.

[0080] Through the combination of the above attributes, events and behaviors, microgrid equipment can achieve efficient data reporting and control interaction during operation, providing a basis for the safe, stable and intelligent operation of the system. The real-time status monitoring, event triggering mechanism and behavior calling of the equipment ensure the flexibility and controllability of the system, enabling the microgrid to respond to various operating conditions in a timely manner and improve overall efficiency and reliability.

[0081] Communication protocols include MQTT, WebSocket and HTTP.

[0082] Communication protocols include MQTT, WebSocket and HTTP. Their selection and application in microgrid systems are based on their different characteristics and applicable scenarios. They can effectively support data transmission, control command transmission and real-time communication between devices in the microgrid, including:

[0083] 1.MQTT (Message Queuing Telemetry Transport):

[0084] MQTT is a lightweight, publish / subscribe-based messaging protocol designed for communication in low-bandwidth, unstable network environments. This makes it very suitable for microgrid environments, especially when there are a large number of devices, large data traffic, and poor network conditions. MQTT can achieve reliable data transmission with low resource overhead.

[0085] Lightweight transmission: The MQTT protocol uses very little network bandwidth and has very low message header overhead, which makes it very suitable for resource-constrained devices, such as sensors and controllers in microgrids. These devices usually run in low-power or low-bandwidth network environments. The lightweight nature of MQTT can ensure efficient data transmission and reduce communication delays.

[0086] Publish / Subscribe Mode: Through the publish / subscribe mechanism, MQTT allows multiple devices or system components in a microgrid to share data. A device can publish a message to a topic as a publisher, and other devices or platforms that subscribe to the topic will receive the message. This mode not only improves the flexibility of communication, but also reduces the complexity of direct communication between devices. It is particularly suitable for scenarios where multiple devices work together in a microgrid.

[0087] QoS (Quality of Service) mechanism: The MQTT protocol supports three different levels of service quality (QoS 0, QoS1, QoS2), providing corresponding transmission guarantees for different types of messages. In microgrids, the QoS mechanism allows high transmission reliability to be set for key messages (such as faults and alarm events), ensuring that messages can still be reliably transmitted and reach the target device or platform even when the network is unstable.

[0088] 2. WebSocket:

[0089] WebSocket is a bidirectional communication protocol based on TCP. It can establish a persistent connection between the client and the server and support real-time, bidirectional data exchange. This feature makes WebSocket very suitable for application scenarios that require frequent data updates and low-latency communication.

[0090] Real-time two-way communication: Unlike the traditional HTTP protocol, WebSocket allows the server and client to send data to each other at the same time after the connection is established, without the need to frequently re-establish the connection. This feature is particularly important in microgrid systems, especially in scenarios that require real-time data monitoring, device control, and status feedback. Through WebSocket, the control center can receive data from the device in real time and send instructions to the device immediately to ensure the system's response speed;

[0091] Low latency and low overhead: WebSocket avoids the request-response cycle in traditional HTTP through long connections, so the latency is lower and the overhead is smaller. Devices in the microgrid can maintain a long-term connection with the control center through WebSocket, which is particularly suitable for situations where critical equipment needs to update its status in real time or perform emergency operations;

[0092] Full-duplex communication: WebSocket's full-duplex communication mode enables devices and platforms to send and receive data simultaneously without waiting for each other's response, which means that in a microgrid, devices can continue to receive new control instructions while performing tasks, greatly improving the system's concurrent processing capabilities.

[0093] 3. HTTP (HyperText Transfer Protocol):

[0094] HTTP is one of the most common application layer protocols, mainly used for request-response communication between devices and platforms. Although HTTP has a relatively large overhead, it still has advantages in certain specific scenarios, especially when a large amount of data needs to be transmitted or real-time communication is not required;

[0095] Request-response model: HTTP is based on the request-response model and is suitable for scenarios in microgrids that require periodic or large data transmission. For example, devices can periodically report data logs or upload device maintenance information to the management platform through HTTP. In addition, HTTP is also commonly used for large file transmission or more complex task scheduling between devices and platforms.

[0096] Universality and compatibility: The HTTP protocol is very mature and universal, and is compatible with almost all devices and platforms. Most devices in a microgrid can communicate with the backend system via HTTP, so it is suitable as a basic communication protocol between components in a microgrid system, especially when standardized data transmission is required between devices.

[0097] RESTful API compatibility: HTTP protocol is widely used in RESTful API, which is suitable for controlling devices and querying data through API interfaces in microgrid platforms. The management platform can obtain the current status or historical operation data of the device through HTTP requests, or adjust the operating parameters of the device by sending control commands. This API call method based on standard HTTP makes system integration more convenient and reduces the complexity of custom protocols.

[0098] Summarize:

[0099] The MQTT protocol is suitable for the communication needs of low-bandwidth, low-power devices in microgrids, especially for status monitoring and alarm management of large-scale devices. WebSocket provides real-time, two-way communication capabilities, which can meet the needs of low-latency two-way data exchange between devices and platforms, and is suitable for device control and data synchronization that require fast response. Although HTTP has relatively large communication overhead, it still has advantages in scenarios such as device data reporting, system integration, and large file transfer, especially when standardized and highly compatible communication interfaces are required. Through the combined application of these protocols, the microgrid system can flexibly select the most appropriate communication method in different scenarios to achieve efficient, low-latency, and reliable data transmission and control instruction issuance;

[0100] The messages forwarded in the message agent are divided into event messages and behavior messages. Event messages include basic information reporting, alarm information reporting, and fault message reporting. Behavior messages are responsible for downlink control.

[0101] The steps to implement the message broker are as follows:

[0102] (a) Priority Assignment

[0103] Each arriving message is assigned a static priority, which remains unchanged throughout the life cycle of the message. The priorities of event messages and behavior messages are as follows: fault message, alarm message, behavior message, and basic information. After a message arrives, it enters the cache queue first.

[0104] (b) Message preemption

[0105] In an environment where multiple messages arrive, if a high-priority message becomes ready, that is, a new message arrives, the high-priority message will preempt the forwarding of the low-priority message being forwarded, and the preempted low-priority message will be cached until all higher-priority messages are forwarded;

[0106] (c) Message Scheduling

[0107] The scheduler determines the next message to be forwarded based on the message priority and the message ready time, ensuring that the message with the highest priority is processed first.

[0108] The messages forwarded in the message agent are divided into event messages and behavior messages. These two types of messages have different functions. Event messages are mainly used for uploading device status and system monitoring, while behavior messages are used by the platform to issue control instructions to devices. Among them:

[0109] 1. Event message: Event message covers the status data generated during the operation of the equipment, including three types of basic information reporting, alarm information reporting and fault information reporting;

[0110] Basic information reporting: This is the daily operation data sent by the device regularly or according to system requirements, usually including the device's operating status and parameter values ​​(such as voltage, current, power, etc.), which are used by the platform to monitor the health status of the device and evaluate its operating efficiency. Basic information reporting frequency is high but the priority is low, because this data is for long-term trend analysis and status monitoring, and usually does not require immediate processing;

[0111] Alarm information reporting: When certain operating parameters of the equipment exceed the preset safety threshold, an alarm message will be triggered. Alarm information has a higher priority and is intended to alert the system or operator to potential equipment anomalies to avoid more serious problems. Alarm information reporting requires the system to process quickly so that timely intervention can be made to prevent further deterioration of the equipment's operating status;

[0112] Fault information reporting: Fault information is the reporting information triggered when a serious problem occurs in the equipment or when it cannot operate normally. It has the highest priority. Fault information reporting not only indicates that part or all of the functions of the equipment have been lost, but also requires the system to respond immediately and take measures, such as switching to backup equipment, reducing load or initiating emergency plans to ensure the overall operation stability of the microgrid.

[0113] 2. Behavior messages: Behavior messages are initiated by the platform or business system and are mainly used to control equipment, including starting, stopping, adjusting power, switching operating modes, etc. Behavior messages are usually sent by the platform when it detects equipment abnormalities or needs to adjust operating parameters. Although behavior messages affect the real-time operation of equipment, their priority is usually lower than alarm and fault information, unless the equipment status needs to be changed immediately in specific circumstances, such as emergency shutdown operations;

[0114] The implementation steps of the message agent are divided into priority allocation, message preemption and message scheduling. The above three steps can ensure that when the system processes a large number of messages of different priorities, key messages can be processed first, thereby improving the overall efficiency and response speed of the microgrid.

[0115] (a) Priority Assignment

[0116] Each incoming message is assigned a static priority, which remains unchanged during the life cycle of the message. The priority is assigned based on the importance and urgency of the message, from high to low: fault message, alarm message, behavior message, and basic information;

[0117] Priority remains static: The core purpose of static priority design is to ensure that critical events can be processed first in any case, to prevent dynamic adjustment of priority from causing confusion in system scheduling. With fixed priority, the system can process messages stably and predictably, ensuring that high-priority messages will not be delayed due to system busyness or resource competition.

[0118] Cache queue management: When a message arrives, it will enter the corresponding cache queue according to its priority. The system will first process the messages in the high-priority queue, while low-priority messages will queue up for processing. This design effectively avoids low-priority messages occupying system resources, allowing high-priority messages to be processed quickly.

[0119] (b) Message preemption

[0120] In the message preemption mechanism, if a high-priority message becomes ready, that is, when a new high-priority message arrives, it will preempt the transmission of the currently processed low-priority message;

[0121] Design of preemption mechanism: high-priority messages preempt low-priority message transmission to ensure that key data will not be delayed due to system busyness. This design is a necessary means to cope with multi-tasking environments. When alarm or fault information arrives, it can interrupt the current behavior message or basic information being processed and push the high-priority message to the system resources for processing;

[0122] Implementation of the cache mechanism: Preempted low-priority messages will not be discarded, but cached in the queue and will continue to be processed after the high-priority messages are processed. This ensures that high-priority messages are responded to in a timely manner, while low-priority messages can also be processed when system resources are released, avoiding data loss or excessive delays.

[0123] (c) Message Scheduling

[0124] The scheduler is responsible for scheduling messages in multiple cache queues and determining the next message to be processed based on the message priority and the message ready time;

[0125] Scheduling priority principle: The scheduler first selects high-priority messages for processing based on the priority of the messages, and then sorts them according to the ready time (i.e. the time when the message arrives in the queue) in the same priority queue. This ensures that the system can not only prioritize the processing of critical messages, but also prioritize the processing of the first-arrived messages, thus avoiding long waiting times for messages;

[0126] Dynamic adjustment of processing order: During the processing process, the scheduler detects the arrival of new messages in real time and dynamically adjusts the processing order of messages. If a new high-priority message arrives, the scheduler will immediately interrupt the transmission of low-priority messages and start processing the new high-priority message. In this way, the system can flexibly respond to complex message environments and ensure efficient resource utilization and response time.

[0127] The low-latency message proxy algorithm consists of four parts:

[0128] (1) Symbol definition:

[0129] Let M represent the set of messages:

[0130] Each message m ∈ M has a fixed priority p(m), where p:M→N is the priority function;

[0131] Q(t) represents the cache queue at time t, where

[0132] status(m,t) indicates the status of message m at time t, which can be set to "ready" or "not ready";

[0133] C(t) represents the message being forwarded at time t;

[0134] (2) Priority allocation:

[0135] The priority p(m) is determined in advance according to the message type and remains unchanged during the life cycle of the message;

[0136] (3) Message preemption:

[0137] Define the preemption function preempt(m, m′, t) as:

[0138]

[0139] If preempt(m,C(t),t)=1, message m preempts C(t), and C(t) is placed in Q(t);

[0140] (4) Message Scheduling:

[0141] The scheduling function schedule(Q(t)t) selects the ready message m with the highest priority in Q(t) as C(t+1):

[0142]

[0143] Message m is removed from Q(t) and forwarding begins.

[0144] In the above formula:

[0145] Preemption is triggered only when the priority of a message m is higher than the message m′ currently being processed and the message m is in the "ready" state. Preemption means that high-priority messages will interrupt the processing of low-priority messages. Therefore, the low-latency message proxy algorithm defined by this formula achieves optimal utilization of system resources through static priority allocation, preemption mechanism and priority-based scheduling. Especially in a multi-task and multi-message concurrent environment, the system can be flexibly scheduled according to priority and message status to ensure timely processing of key tasks, reduce message transmission delays, and ensure efficient and stable operation of the microgrid system.

[0146] Embodiment 2:

[0147] When the network status is unstable and packet loss occurs, the low-latency message proxy algorithm gives priority to using a communication protocol with a confirmation mechanism for data transmission, including: using the quality assurance level mechanism in the MQTT protocol to ensure reliable message delivery in unstable network conditions; automatically retransmitting unconfirmed critical messages through a message retransmission mechanism until successful confirmation feedback is received.

[0148] When the network status is unstable or there is packet loss, the low-latency message proxy algorithm ensures reliable data transmission by optimizing the communication protocol, especially ensuring the integrity and timeliness of high-priority data during the transmission of critical messages. In this scenario, the reliability and confirmation mechanism of message transmission are crucial, so the system can give priority to communication protocols with confirmation mechanisms for data transmission, including the following aspects:

[0149] 1. Give priority to using communication protocols with confirmation mechanisms

[0150] When the network status is unstable, such as packet loss, delay jitter or network congestion, traditional communication protocols may cause data loss or delay, affecting the accuracy of messages and the overall performance of the system. To cope with this situation, the system selects a protocol with a message confirmation mechanism to ensure that the message can be successfully transmitted to the target device. In the specific implementation, the system gives priority to the MQTT protocol, which can provide reliable transmission guarantees in unstable networks through a built-in confirmation mechanism and lightweight design.

[0151] 2. Quality Assurance Level Mechanism in MQTT Protocol

[0152] The MQTT protocol has designed three different quality of service (QoS) levels, namely QoS 0, QoS1 and QoS2, to meet different reliability requirements. In the case of network instability or packet loss, the low-latency message proxy algorithm uses MQTT's advanced quality of service mechanism to ensure that key messages can be reliably delivered:

[0153] QoS 0 (At most once): After the message is sent, the receiver is not required to return an acknowledgment, and the message may be lost. This mode is suitable for non-critical data that does not require high reliability transmission;

[0154] QoS1 (At least once): The message is delivered at least once. The sender needs to wait for the receiver's confirmation. If the confirmation is not received, the message will be resent until the confirmation is successfully received. This mode can ensure that the message will not be lost in the case of unstable network, but it may cause message duplication;

[0155] QoS2 (Exactly once): ensures that the message is delivered only once to avoid duplication and loss of messages. This mode uses a series of handshake protocols to ensure the integrity of message delivery and is very suitable for transmitting critical data with high reliability requirements.

[0156] In actual applications, when the system detects that the network condition is unstable, it will automatically adjust the QoS level of the message. For example, basic information reporting may use QoS 0, while critical alarm and fault messages will use QoS2 to ensure that these high-priority messages can be fully and only once transmitted to the receiving end.

[0157] 3. Message resending mechanism

[0158] In a network environment with a high packet loss rate, messages that fail to receive confirmation may be lost, resulting in system response delays or data loss. To cope with this situation, the low-latency message proxy algorithm ensures reliable transmission of critical data through a message retransmission mechanism. In the QoS1 and QoS2 modes of the MQTT protocol, if a message is sent without receiving confirmation from the recipient, the system will automatically trigger the retransmission mechanism and resend the unconfirmed message until a successful confirmation feedback is received;

[0159] Automatic retransmission mechanism: In the retransmission mechanism, the system dynamically adjusts the retransmission frequency and interval time according to the priority of unconfirmed messages. High-priority messages (such as fault information and alarm information) will be set to be retransmitted first to ensure that they are confirmed as soon as possible in an unstable network. For low-priority messages, the system may extend the retransmission interval to reduce the occupation of system resources. This can prevent network congestion caused by excessive retransmission and ensure the reasonable allocation of system resources.

[0160] Intelligent retransmission strategy: The system can intelligently adjust the retransmission strategy according to the current network status. If the network fluctuates greatly and the packet loss rate is high, the system will shorten the retransmission interval and increase the number of retransmissions to ensure that the message is delivered as soon as possible. If the network returns to stability, the system will reduce the retransmission frequency to avoid wasting resources. This intelligent scheduling mechanism is closely integrated with network status monitoring, so that the system can maintain high-reliability data transmission under any network conditions;

[0161] Confirmation feedback mechanism: Once a message is successfully received, the system will immediately stop retransmitting to avoid redundant transmission and ensure the efficiency of the system. At the same time, the received confirmation feedback can also be used as a basis for evaluating the system's network status to help further optimize network strategies.

[0162] 4. System response and error handling mechanism

[0163] The low-latency message proxy algorithm not only relies on the MQTT protocol and message retransmission mechanism, but also combines a complete system response and error handling mechanism to ensure that the system can maintain stable operation even under complex network conditions;

[0164] Timeout mechanism: After multiple retransmissions, if the message is still not confirmed, the system will trigger the timeout mechanism. At this time, the system may choose to change the communication protocol or switch to an alternative network path to ensure that critical data transmission is not interrupted. At the same time, the system will send an alarm to the platform or administrator to notify the current network abnormality and take timely measures;

[0165] Load balancing: When the frequency of message retransmission is too high, resulting in an overload on the network, the system will adjust the data transmission path and frequency through the load balancing mechanism to prevent a communication node or network link from being overloaded and affecting the overall performance. In this way, the system can minimize the impact of network failures on data transmission;

[0166] Logging and analysis: Each resent message and confirmation feedback will be recorded in the system log for subsequent analysis. These logs can not only help the system optimize the resend strategy, but also be used for troubleshooting to identify potential network bottlenecks or unstable factors.

[0167] 5. Overall optimization effect

[0168] By introducing the QoS mechanism and message retransmission strategy in the MQTT protocol, the low-latency message proxy algorithm can ensure the reliable transmission of high-priority messages when the network is unstable, especially in systems such as microgrids that have extremely high requirements for real-time and stability, and can effectively reduce delays and data loss caused by network problems;

[0169] Guarantee in case of faults and alarms: When a microgrid device fails, the system can ensure that the fault message is delivered to the control center through the MQTT QoS2 mechanism, ensuring that it is received only once, avoiding misoperation or information duplication caused by network packet loss or delay;

[0170] Improved reliability under complex network conditions: By dynamically adjusting the retransmission frequency and combining it with an intelligent network scheduling mechanism, the system can maintain efficient operation when the network is unstable, ensuring that critical data is not lost while avoiding resource waste caused by excessive retransmissions.

[0171] Although embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions and variations may be made to the embodiments without departing from the principles and spirit of the present invention, and that the scope of the present invention is defined by the appended claims and their equivalents.

Claims

1. A low-latency microgrid data transmission agent method, characterized in that: The following steps are involved: A. Build physical models of devices based on the properties, events, and behaviors of microgrid devices; B. Device data preprocessing: According to the event definition of the object model, the data is processed before it is sent: C. Data transmission: Use communication protocol to transmit data; D. Message proxy: A low-latency message proxy algorithm is used to proxy and forward messages. The algorithm is used to determine the message priority. The high-priority messages are forwarded first, and the low-priority messages are cached. The low-latency message proxy algorithm includes four parts: (1) Symbol definition: Let M represent the set of messages; Each message m∈M has a fixed priority p(m), where p:M→N is a priority function; Q(t) represents the cache queue at time t, where status(m,t) indicates the status of message m at time t, which can be set to "ready" or "not ready"; C(t) represents the message being forwarded at time t; (2) Priority allocation: The priority p(m) is determined in advance according to the message type and remains unchanged during the life cycle of the message; (3) Message preemption: Define the preemption function preempt(m, m′, t) as: If preempt(m,C(t),t)=1, message m preempts C(t), and C(t) is placed in Q(t); (4) Message Scheduling: The scheduling function schedule(Q(t)t) selects the ready message m with the highest priority in Q(t) as C(t+1): Message m is removed from Q(t) and forwarding begins.

2. A low-latency microgrid data transmission agent method according to claim 1, characterized in that: The attributes of the microgrid device include parameters and status data of the microgrid device during operation, including identification, name, definition, constraint, type and description.

3. A low-latency microgrid data transmission agent method according to claim 2, characterized in that: The attributes of the microgrid device support two types: read-write and read-only. Read-write means that the attribute can be reported from the device to the platform and can also be controlled from the platform. Read-only means that the attribute is only reported from the device to the platform.

4. A low-latency microgrid data transmission agent method according to claim 1, characterized in that: The events of the microgrid device include data initiated by the device during operation that needs to be perceived by the user business system, including three event types: information, alarm, and fault. Information is a reporting event generated by the device in normal business processing, an alarm is a reporting event triggered by excessively high values ​​of certain attributes of the device under normal operation, and a fault is a reporting event triggered by the device failing to operate normally.

5. A low-latency microgrid data transmission agent method according to claim 1, characterized in that: The behavior of the microgrid device includes a callable method provided by the device for the business system to request and receive a response.

6. A low-latency microgrid data transmission agent method according to claim 1, characterized in that: The communication protocols include MQTT, WebSocket and HTTP.

7. A low-latency microgrid data transmission agent method according to claim 1, characterized in that: The messages forwarded in the message proxy are divided into event and behavior messages. The event messages include basic information reporting, alarm information reporting, and fault message reporting. The behavior messages are responsible for downlink control.

8. A low-latency microgrid data transmission agent method according to claim 7, characterized in that: The message agent implementation steps are as follows: (a) Priority Assignment Each arriving message is assigned a static priority, which remains unchanged throughout the life cycle of the message. The forwarding priorities of the event message and behavior message are, from high to low, fault message, alarm message, behavior message, and basic information. After the message arrives, it enters the cache queue first; (b) Message preemption In an environment where multiple messages arrive, if a high-priority message becomes ready, that is, a new message arrives, the high-priority message will preempt the forwarding of the low-priority message being forwarded, and the preempted low-priority message will be cached until all higher-priority messages are forwarded; (c) Message Scheduling The scheduler determines the next message to be forwarded according to the priority of the message and the ready time of the message, ensuring that the message with the highest priority is processed first.

9. A low-latency microgrid data transmission agent method according to any one of claims 1 to 8, characterized in that: The low-latency message proxy algorithm preferentially uses a communication protocol with a confirmation mechanism for data transmission when the network status is unstable and packet loss exists, including: Adopt the quality assurance level mechanism in the MQTT protocol to ensure reliable message delivery in unstable network conditions; The unconfirmed critical messages are automatically resent through the message resending mechanism until successful confirmation feedback is received.

Images