An energy system data interaction method and system based on artificial intelligence

Abstract

This invention discloses an artificial intelligence-based energy system data interaction method and system. The method includes: receiving encrypted raw operating data and fuzzy energy consumption preference declarations; extracting real-time physical state feature vectors of local devices based on the raw operating data; performing localized energy consumption intent reasoning based on the real-time physical state feature vectors and fuzzy energy consumption preference declarations to generate fine-grained energy consumption intent vectors; encapsulating the fine-grained energy consumption intent vectors into intent expression data packets; at the regional energy coordinator, aggregating the received intent expression data packets from multiple nodes to generate an encrypted interaction confirmation instruction set; and distributing the encrypted interaction confirmation instruction set to relevant matching nodes to trigger energy data flow interaction and execution between nodes based on interaction terms. Using this invention, the executability of energy interaction intents can be improved, and the collaborative efficiency of distributed energy systems can be optimized.

Description

Technical Field

[0001] This invention belongs to the field of artificial intelligence technology, specifically an energy system data interaction method and system based on artificial intelligence. Background Technology

[0002] With the rapid development of distributed energy systems, traditional energy data interaction methods face numerous challenges: on the one hand, the massive operational data and personalized demands from users are difficult for the power grid system to parse efficiently, resulting in insufficient accuracy in supply and demand matching; on the other hand, centralized dispatching models pose privacy risks and suffer from low cross-node coordination efficiency. Existing technologies typically rely on plaintext data transmission or rigid demand commands, failing to accommodate both fuzzy user preferences and dynamic intent reasoning capabilities, thus restricting the flexibility and security of energy interaction. Furthermore, in point-to-point energy transactions, the lack of standardized and verifiable intent expression mechanisms can easily lead to coordination conflicts or trust issues. Summary of the Invention

[0003] The purpose of this invention is to provide an energy system data interaction method and system based on artificial intelligence, so as to overcome the shortcomings of the existing technology, improve the executability of energy interaction intentions, and optimize the collaborative efficiency of distributed energy systems.

[0004] One embodiment of this application provides a data interaction method for an energy system based on artificial intelligence, the method comprising: Receive encrypted raw operating data and user-preset fuzzy energy consumption preference declaration from distributed energy user terminal, and extract real-time physical state feature vector of local device based on the raw operating data, wherein the fuzzy energy consumption preference declaration includes fuzzy energy consumption target range or priority label; Using a lightweight edge AI model deployed on the user terminal side, localized energy consumption intention reasoning is performed based on the real-time physical state feature vector and the fuzzy energy consumption preference declaration to generate a fine-grained energy consumption intention vector that represents the user's specific, executable but encrypted needs. The energy consumption intention vector includes specific quantitative requirements for grid interaction power, charging and discharging time windows, and adjustable margins. The fine-grained energy consumption intent vector is encapsulated into a structured, standardized intent expression data packet and broadcast to neighboring energy nodes and the regional energy coordinator via a peer-to-peer network. At the regional energy coordinator, the received intent expression data packets from multiple nodes are aggregated, and based on preset consensus rules, intent compatibility verification and secure interaction matching are performed to generate an encrypted interaction confirmation instruction set containing the matching node pairs and their interaction terms. The encrypted interaction confirmation instruction set is distributed to relevant matching nodes, triggering automated, point-to-point energy data flow interaction and execution between nodes based on the interaction terms. At the same time, the key summary information of the execution result is synchronized to the blockchain network for immutable evidence storage.

[0005] Optionally, the step of receiving encrypted raw operating data and a user-preset fuzzy energy consumption preference statement from a distributed energy user terminal, and extracting a real-time physical state feature vector of the local device based on the raw operating data, wherein the fuzzy energy consumption preference statement includes a fuzzy energy consumption target range or priority label, including: The encrypted raw operating data is decrypted in real time, and the plaintext time-series data stream containing voltage fluctuations, current harmonics, and temperature gradients is output. The plaintext time-series data stream is input into the physical feature extraction engine, and the fundamental frequency and transient components are separated by wavelet packet transform, outputting a set of device-level physical state feature fragments; Parse the user's fuzzy energy consumption preference declaration, quantify the target interval as a probability distribution using an interval membership function, and output a priority label vector; By fusing a set of physical state feature fragments with a priority label vector, a real-time physical state feature vector is generated through a feature cross-layer.

[0006] Optionally, the step of utilizing a lightweight edge AI model deployed on the user terminal side to perform localized energy consumption intent reasoning based on the real-time physical state feature vector and the fuzzy energy consumption preference declaration generates a fine-grained energy consumption intent vector that represents the user's specific, executable, but encrypted needs. This energy consumption intent vector includes specific quantitative requirements for grid interaction power, charging / discharging time windows, and adjustable margins, including: Input the real-time physical state feature vector into the temporal convolution module to extract the device operation cycle pattern and output the device state evolution map; A fuzzy rule base is constructed based on priority label vectors, and an adaptive neural inference engine is used to match the optimal rule and output the preliminary intent constraint boundary. Based on the device state evolution graph and intent constraint boundary, fine-grained intent parameters are generated through a reinforcement learning policy network; The executableness of the intent parameters is verified, conflicting schemes are filtered through the physical constraint solver, and a set of valid intent parameters is output. The effective intent parameter set is encoded into an energy consumption intent vector, encrypted using the lightweight national cryptographic algorithm SM4, and the encrypted fine-grained energy consumption intent vector is output.

[0007] Optionally, the step of encapsulating the fine-grained energy consumption intent vector into a structured, standardized intent expression data packet and broadcasting it to neighboring energy nodes and the regional energy coordinator via a peer-to-peer network includes: Parse the fine-grained energy consumption intent vector, construct the intent metadata header, and output a structured intent description framework; The intent description framework is bound to a fine-grained energy-consuming intent vector, and intent expression data packets are generated through TLV encoding. Add a lightweight blockchain identity signature to the intent expression data packet to generate a standardized data packet with authentication; Based on a geographic location hash table, nearby energy nodes are selected, and standardized data packets are broadcast to nearby energy nodes and the regional energy coordinator via a low-latency P2P protocol.

[0008] Optionally, at the regional energy coordinator, the received intent expression data packets from multiple nodes are aggregated, and based on preset consensus rules, intent compatibility verification and secure interaction matching are performed to generate an encrypted interaction confirmation instruction set containing the matching node pairs and their interaction terms, including: The regional energy coordinator receives intent expression data packets from multiple nodes, verifies identity signatures through zero-knowledge proofs, and outputs a set of trusted nodes and their intent expression data packets. Deconstruct the intent expression data packet to extract power grid interaction power and time window parameters, and construct a multi-dimensional intent compatibility matrix; Input the compatibility matrix into the consensus engine based on Byzantine fault tolerance to verify the supply and demand balance constraints among nodes and output a candidate set of matching node pairs. The matching nodes perform a security assessment on the candidate set, verify the authenticity of the data through privacy-preserving calculations, and generate a risk scoring matrix. Based on the risk scoring matrix and the interaction terms template, an encrypted interaction confirmation instruction set is generated.

[0009] Optionally, the step of distributing the encrypted interaction confirmation instruction set to relevant matching nodes, triggering automated, peer-to-peer energy data flow interaction and execution between nodes based on the interaction terms, and simultaneously synchronizing the key summary information of the execution result to the blockchain network for tamper-proof notarization, includes: The encrypted interaction confirmation instruction set is pushed to the matching node pair through a secure group key distribution mechanism; After receiving the encrypted interaction confirmation instruction, the matching node automatically decrypts it, triggers the smart contract to parse the interaction terms, and outputs control instructions for the energy data stream. Point-to-point energy interaction is executed based on control commands, and key indicators including power and timestamps are collected in real time to generate execution summary metadata. The execution digest metadata is submitted to the blockchain network, and immutable evidence is stored through a practical Byzantine consensus algorithm.

[0010] Another embodiment of this application provides an artificial intelligence-based energy system data interaction system, the system comprising: The receiving module is used to receive encrypted raw operating data and user-preset fuzzy energy consumption preference declarations from distributed energy user terminals, and extract real-time physical state feature vectors of local devices based on the raw operating data. The fuzzy energy consumption preference declarations include fuzzy energy consumption target ranges or priority labels. The inference module is used to utilize a lightweight edge AI model deployed on the user terminal side to perform localized energy consumption intention inference based on the real-time physical state feature vector and the fuzzy energy consumption preference declaration, and generate a fine-grained energy consumption intention vector that represents the user's specific, executable but encrypted nature. The energy consumption intention vector includes specific quantitative requirements for grid interaction power, charging and discharging time windows, and adjustable margins. The encapsulation module is used to encapsulate the fine-grained energy consumption intent vector into a structured and standardized intent expression data packet, and broadcast it to neighboring energy nodes and regional energy coordinators through a point-to-point network. The matching module is used at the regional energy coordinator to aggregate the intent expression data packets received from multiple nodes, and based on preset consensus rules, to perform intent compatibility verification and secure interaction matching, and generate an encrypted interaction confirmation instruction set containing the matching node pairs and their interaction terms. The interaction module is used to distribute the encrypted interaction confirmation instruction set to relevant matching nodes, trigger automated, point-to-point energy data flow interaction and execution between nodes based on the interaction terms, and simultaneously synchronize the key summary information of the execution result to the blockchain network for tamper-proof evidence storage.

[0011] Another embodiment of this application provides a storage medium storing a computer program, wherein the computer program is configured to execute the method described in any of the preceding claims when running.

[0012] Another embodiment of this application provides an electronic device including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the method described in any of the preceding claims.

[0013] Compared with existing technologies, this invention provides an AI-based energy system data interaction method. This method receives encrypted raw operating data and fuzzy energy consumption preference declarations; extracts real-time physical state feature vectors of local devices based on the raw operating data; performs localized energy consumption intent reasoning based on the real-time physical state feature vectors and fuzzy energy consumption preference declarations to generate fine-grained energy consumption intent vectors; encapsulates these fine-grained energy consumption intent vectors into intent expression data packets; at the regional energy coordinator, aggregates the received intent expression data packets from multiple nodes to generate an encrypted interaction confirmation instruction set; and distributes the encrypted interaction confirmation instruction set to relevant matching nodes, triggering energy data flow interaction and execution between nodes based on interaction terms. This improves the executability of energy interaction intents and optimizes the collaborative efficiency of distributed energy systems. Attached Figure Description

[0014] Figure 1 A hardware structure block diagram of a computer terminal for an energy system data interaction method based on artificial intelligence, provided in an embodiment of the present invention; Figure 2 A flowchart illustrating an artificial intelligence-based energy system data interaction method provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of an energy system data interaction system based on artificial intelligence, provided as an embodiment of the present invention. Detailed Implementation

[0015] The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0016] This invention first provides an artificial intelligence-based energy system data interaction method, which can be applied to electronic devices, such as computer terminals, specifically ordinary computers.

[0017] The following detailed explanation uses a computer terminal as an example. Figure 1 This is a hardware structure block diagram of a computer terminal for an artificial intelligence-based energy system data interaction method provided in an embodiment of the present invention. (See diagram below.) Figure 1 As shown, the computer device includes a processor, memory, and network interface connected via a system bus, wherein the memory may include non-volatile storage media and internal memory.

[0018] Non-volatile storage media can store operating systems and computer programs. These computer programs include program instructions that, when executed, cause the processor to perform any artificial intelligence-based energy system data interaction method.

[0019] The processor provides computing and control capabilities, supporting the operation of the entire computer device.

[0020] Internal memory provides an environment for the execution of computer programs in non-volatile storage media. When executed by a processor, the computer program enables the processor to perform any artificial intelligence-based energy system data interaction method.

[0021] This network interface is used for network communication, such as sending assigned tasks. Those skilled in the art will understand that... Figure 1 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0022] It should be understood that the processor can be a Central Processing Unit (CPU), but it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Among these, a general-purpose processor can be a microprocessor or any conventional processor.

[0023] See Figure 2 The present invention provides an artificial intelligence-based energy system data interaction method, which may include the following steps: S201, receive encrypted raw operating data and user-preset fuzzy energy consumption preference declaration from distributed energy user terminal, extract real-time physical state feature vector of local device based on the raw operating data, wherein the fuzzy energy consumption preference declaration includes fuzzy energy consumption target range or priority label; Specifically, it can decrypt encrypted raw operating data in real time and output plaintext time-series data streams containing voltage fluctuations, current harmonics, and temperature gradients; Encrypted Raw Operational Data (EROD) uploaded by distributed energy user terminals (such as photovoltaic inverters, energy storage battery management systems, and smart meters) via secure communication protocols (such as TLS 1.3) first enters the secure enclave (SE) of the edge computing module. This area is physically isolated by a hardware-level Trusted Execution Environment (TEE) such as Intel SGX or ARM TrustZone, ensuring that the decryption process is not interfered with by malware. The decryption core uses the Chinese national cryptographic SM2 asymmetric algorithm and the SM4 symmetric algorithm in collaboration: first, the user terminal's unique private key (PK) is used to decrypt the SM2-encrypted session key (SK), and then the SK is used to decrypt the SM4-encrypted raw data stream. The decryption engine is designed with a pipelined architecture, supporting parallel processing of multiple data packets, with latency strictly controlled within 10 milliseconds (ms) to meet real-time requirements. The decrypted data is a plaintext time-series data stream (PTSDS), whose data structure contains three core physical quantities: voltage fluctuation (VF) data, which records the instantaneous voltage deviation at a sampling frequency of 1000 times per second; current harmonic (CH) data, which is pre-decomposed into the amplitude of the 2nd to 50th harmonic components through FFT (Fast Fourier Transform); and temperature gradient (TG) data, which is synchronously collected by multiple sensor nodes (such as the surface of the battery module and the heat sink of the power device) at a frequency of 1Hz to record the spatial temperature difference change.

[0024] To ensure data integrity, a dynamic verification mechanism is embedded in the decryption process: each batch of decrypted data is appended with a Cyclic Redundancy Check (CRC-32), and if the verification fails, a data retransmission protocol is triggered. The decrypted plaintext data stream immediately enters a memory encryption buffer (MEB) and is temporarily stored using AES-XTS (Advanced Encryption Standard - XEX with Ciphertext Theft) mode to prevent physical memory theft attacks. Simultaneously, the system monitors the decryption load in real time, and automatically activates hardware acceleration cards (such as cryptographic cards supporting national cryptographic algorithms) to share the computing power when the data throughput exceeds a threshold (e.g., 1Gbps), avoiding CPU overload on edge devices. The decryption module's output interface is designed with dual channels: the primary channel transmits high-priority real-time data (e.g., voltage surge events), and the backup channel transmits steady-state data (e.g., temperature baselines), ensuring the transmission priority of critical physical quantities (VF, CH, TG). The final output PTSDS data stream carries a precise timestamp (time synchronization accuracy ±1ms) and a device ID tag, providing structured input for subsequent feature extraction.

[0025] To address interference from the industrial environment, the decryption module integrates noise suppression algorithms: sliding window mid-range filtering (Window Size = 50 sampling points) is used for voltage fluctuation data to eliminate pulse interference; spectral calibration is performed on current harmonic data, correcting measurement deviations based on pre-stored device characteristic harmonic templates (such as the 5th and 7th dominant harmonics). Temperature gradient data is reconstructed from discrete sensor data into a continuous temperature field using spatial interpolation algorithms (such as the inverse distance weighting method). Operation logs generated during the decryption process (such as decryption time and error counts) are uploaded to the security audit platform in real time for abnormal behavior analysis (e.g., high-frequency decryption failures may indicate an attack). Thus, the original encrypted data is transformed into a timestamped three-dimensional time-series data stream (voltage, harmonics, temperature) that can be directly used for physical state analysis, providing clean input for the feature extraction engine.

[0026] The plaintext time-series data stream is input into the physical feature extraction engine, and the fundamental frequency and transient components are separated by wavelet packet transform, outputting a set of device-level physical state feature fragments; The core of the Physical Feature Extraction Engine (PFEE) is the Wavelet Packet Transform (WPT) processor. WPT uses the db4 wavelet basis (Daubechies 4th order wavelet) due to its balance of tight support and regularity, making it suitable for analyzing non-stationary signals from energy equipment. The input three-dimensional time-series data stream (VF, CH, TG) is first time-domain aligned: voltage and current data are interpolated to a 10kHz sampling rate, and temperature data is downsampled to 10Hz. The WPT decomposition layer is set to 5 layers, generating 32 sub-bands (SB) within the 0-5kHz frequency band. For voltage fluctuation data, the fundamental frequency component (50Hz / 60Hz) is reconstructed from the low-frequency coefficients of the first layer, while transient components (such as voltage sags) are captured by the high-frequency coefficients of the third to fifth layers. Current harmonic data is analyzed by calculating the energy entropy of the sub-bands to identify the dominant harmonic groups (such as the 23rd-25th harmonic groups indicating converter faults).

[0027] Feature extraction employs a dual-path architecture: Path 1 targets steady-state features, calculating the statistics (mean, variance, skewness) of each physical quantity within a 5-second window; for example, the variance of voltage fluctuation (VF) reflects grid stability. Path 2 targets transient features, performing envelope spectrum analysis (ESA) on the sub-bands after WPT decomposition to extract fault characteristic frequency amplitudes (e.g., the 100Hz sideband corresponding to bearing faults). Temperature gradient (TG) processing incorporates thermal image sequence analysis: multi-sensor data is mapped to a two-dimensional temperature matrix, and the thermal diffusion rate is calculated using an optical flow algorithm (Lucas-Kanade method) to form thermal inertia features. All features are sliced ​​according to the device's operating cycle (e.g., the sunrise-sunset cycle of a photovoltaic inverter) to generate a Device-level Physical State Feature Segment Set (DPSS). Each segment contains a 300-dimensional feature vector (100-dimensional steady-state + 200-dimensional transient), with a fixed segment duration of 30 seconds to accommodate dynamic device responses.

[0028] To reduce computational complexity, the engine deploys a feature importance filtering module: a feature weight model pre-trained using the Random Forest (RF) algorithm dynamically filters redundant features (such as irrelevant harmonic components). For example, for energy storage batteries, it retains the amplitude of the second voltage harmonic, which is strongly correlated with the SOC (State of Charge), and the temperature gradient between the positive and negative electrodes; for wind turbine converters, it focuses on the energy of the 17th / 19th current harmonic groups. Before outputting the feature fragment set, it undergoes normalization processing, employing an improved RobustScaler to eliminate the influence of outliers: replacing the mean with the median, and using the interquartile range (IQR) scaling factor. The final DPSS data format is a timestamped HDF5 (hierarchical data format) file group, with each file containing 100 consecutive fragments, for streaming reading by the downstream intent inference module.

[0029] Parse the user's fuzzy energy consumption preference declaration, quantify the target interval as a probability distribution using an interval membership function, and output a priority label vector; User-generated fuzzy energy preference declarations (FEPDs) are input via a natural language interface (e.g., voice commands like "charge during off-peak hours" or a form checkmarking "prioritize hospital power supply"). The parser employs Semantic Slot Filling (SSF) technology, defining four core slots: energy type (e.g., charging / discharging), target interval (e.g., "2 PM to 4 PM"), fuzzy quantifiers (e.g., "approximately" or "at least"), and priority labels (e.g., "high / medium / low"). For target intervals, such as "off-peak hours," the parser automatically maps them to the low-price periods of the local time-of-use pricing model (e.g., 00:00-06:00). For fuzzy quantifiers, a linguistic variable dictionary is constructed; for example, "approximately" corresponds to ±15% fluctuation, and "at least" corresponds to a lower limit constraint.

[0030] The core of quantization is the Interval Membership Function (IMF): Triangular membership functions (Triangular MF) handle symmetric fuzziness (e.g., "approximately 10kW"): parameters are peak point (10kW), left support (8.5kW), and right support (11.5kW). Trapezoidal membership functions handle asymmetric constraints (such as "at least 5kW"): parameters are lower bound (5kW), upper bound (infinity), left slope (0), and right slope (linear decay). Gaussian membership functions (MFs) handle probabilistic preferences (such as "probably generating electricity at noon"): mean (12:00) and standard deviation (1 hour).

[0031] Each IMF outputs a membership value of 0-1, representing the probability that the target value matches the user's declaration. For example, if the user declares "expected discharge power of approximately 20-30kW", then 25kW has a membership value of 1.0, and 18kW has a membership value of 0.4.

[0032] The Priority Tag Vector (PTV) is a three-dimensional normalized vector: [economic weight, environmental weight, reliability weight]. Tag parsing rules: "Economic priority" → [0.8, 0.1, 0.1]; "Low carbon priority" → [0.2, 0.7, 0.1]; "Prioritize supply" → [0.1, 0.1, 0.8].

[0033] The mixed labels are weighted and merged, such as "Prioritizing economy while considering environmental protection" → [0.6, 0.3, 0.1]. The final PTV and membership distribution together constitute the quantification result of user preferences, for example, the output format is JSON structure: { "power_range": {"type": "trapezoid", "params": [20,30,0.2,0.1]}, "time_window": {"type": "gaussian", "params": [14:00, 3600]}, "priority_vector": [0.7, 0.2, 0.1] } By fusing a set of physical state feature fragments with a priority label vector, a real-time physical state feature vector is generated through a feature cross-layer.

[0034] The Feature Crossing Layer (FCL) employs a Tensor Product Fusion (TPF) architecture. Inputs include: Device-level physical state feature fragment set (DPSS): 300×T (T is the number of time fragments); Priority Tag Vector (PTV): 3×1 dimension.

[0035] First, expand PTV into a matrix (3×T) aligned with DPSS time, and then calculate the outer product of the two (OuterProduct): CrossFeature [i,j]=DPSS[i]×PTV[j](i=1..300,j=1..3).

[0036] Generate a 900-dimensional (300×3) primary cross-feature tensor. For example, multiply the battery temperature gradient feature by the "economic weight" to amplify the significance of features during periods sensitive to electricity prices.

[0037] To compress the feature dimension, a self-attention compression (SAC) module is deployed in the cross layer: Reshape the 900-dimensional tensor into a 30×30 matrix (rows = physical feature groups, columns = priority dimensions); Calculate the attention score matrix A = softmax (QK^T / \ sqrt{d}), where the query vector Q and key vector K are generated by linear transformation of the feature matrix, and d=64 is the scaling factor; The original features are weighted and summed by attention weight A to output a 30-dimensional condensed feature vector.

[0038] This process focuses features on key combinations (such as current harmonic distortion rate under high environmental weights) and suppresses irrelevant cross terms.

[0039] The final Real-time Physical State Feature Vector (RPSFV) is generated through three layers of processing: Residual connection: The 300-dimensional features of the original DPSS are concatenated with the 30-dimensional attention output to form a 330-dimensional vector; Feature scaling: Dynamic range scaling (DRS) is used to adapt to different device dimensions, such as scaling photovoltaic current values ​​to [0,1] and temperature gradients to [-1,1]. Temporal smoothing: Causal convolution is used to impose temporal correlation constraints on features of continuous segments, thus avoiding abrupt noise.

[0040] Example output vector format: [Voltage fluctuation entropy, dominant harmonic energy, thermal diffusion rate, economic-temperature cross term...] 330 dimensions in total, updated once per second, serving as standardized input for edge AI models.

[0041] S202, using a lightweight edge AI model deployed on the user terminal side, localized energy consumption intention reasoning is performed based on the real-time physical state feature vector and the fuzzy energy consumption preference declaration, generating a fine-grained energy consumption intention vector that represents the user's specific, executable but encrypted nature. The energy consumption intention vector includes specific quantitative requirements for grid interaction power, charging and discharging time windows, and adjustable margins. Specifically, real-time physical state feature vectors can be input into a temporal convolution module to extract the device's operating cycle pattern and output a device state evolution map. Hierarchical feature extraction in temporal convolution modules: The core component of the lightweight edge AI model is the Temporal Convolutional Module (TCM). This module employs a multi-layered dilated convolutional architecture, with the receptive field size (RFS) of each convolutional kernel progressively increasing. For example, the first layer has an RFS of 8 time steps, the second layer expands to 16 steps, and the third layer reaches 32 steps. This design can capture device operation cycle features ranging from seconds to minutes. When the real-time physical state feature vector (including voltage fluctuation harmonic components, temperature gradient change rate, etc.) is input into the TCM, the first convolutional layer performs sliding calculations on the input sequence through 8 learnable filters (LF) to extract local transient features (such as current drop patterns). The second convolutional layer, based on the output of the first layer, uses a dilation factor (DF=2) to sample the input data at intervals, expanding the RFS to 16 steps to identify medium-cycle patterns (such as the compressor start-stop cycle every 15 minutes). The third layer further sets the DF to 4 and the RFS to cover 32 time steps to capture long-term patterns (such as the hourly photovoltaic power output decay trend). Each convolutional layer is followed by a Gated Linear Unit (GLU) activation function, which filters out noise interference through the sigmoid gating mechanism and retains key features.

[0042] Multi-scale feature fusion and map construction: The outputs of the three convolutional layers are fed into a Feature Pyramid Network (FPN) for cross-scale fusion. The low-level high-frequency features (RFS=8) are compressed into channels using a 1×1 convolution and then matched with the high-level low-frequency features (RFS=32) through a Bidirectional Feature Alignment (BFA) module to match the spatiotemporal resolution. Specifically, BFA uses bilinear interpolation (BI) to upsample low-frequency features while using max pooling (MP) to downsample high-frequency features, ensuring consistent dimensionality. The fused feature tensor is then input into a Self-Attention Mechanism (SAM) to calculate the correlation weight (CW) of features at different time steps. For example, a feature exhibiting a sudden temperature gradient change at a certain moment may have a strong correlation with current harmonic features from 10 minutes prior (CW>0.8), and SAM amplifies this correlation in its output. Finally, a graph generator (GG) maps the time-series features into a topological structure: each time step is a node, the feature value is a node attribute, and the correlation between features is an edge weight, forming a device state evolution graph (DSEG) with spatiotemporal dependencies. This graph is stored using a dual data structure: an adjacency matrix (AM) and a feature matrix (FM).

[0043] Dynamic graph optimization and output verification: To avoid graph overfitting, the edge AI model integrates an online graph pruning algorithm (OGPA). OGPA sets a correlation threshold (CT=0.3) to automatically remove edges in the AM with weights lower than CT (such as weak correlations caused by random noise). Simultaneously, it employs a node importance score (NIS) to dynamically aggregate redundant nodes based on node degree centrality (DC) and feature variance (FV). For example, nodes with stable states for 5 consecutive minutes are merged into a super node (SN) to reduce graph complexity. Before output, the connectivity of the DSEG is checked by a graph validation unit (GVU): if the coverage of the largest connected subgraph (LCS) is lower than a preset value (e.g., 90%), a TCM recalculation is triggered. The final DSEG output contains three key patterns: periodic patterns (such as the air conditioner starting and stopping every 25 minutes), trend patterns (such as the linear decrease in battery SOC), and abnormal patterns (such as voltage drop events marked as red warning nodes).

[0044] A fuzzy rule base is constructed based on priority label vectors, and an adaptive neural inference engine is used to match the optimal rule and output the preliminary intent constraint boundary. The dynamic construction mechanism of the fuzzy rule base: The Priority Tag Vector (PTV) in a user's fuzzy energy consumption preference declaration contains discrete tags (such as "cost priority" and "comfort priority") and a continuous confidence score (CS). The system has a pre-built Base Rule Template Library (BRTL) containing 200 rules in the form of "IF peak electricity price AND equipment interruptible THEN power reduction weight = 0.8". When the PTV is input, the Rule Instantiation Engine (RIE) performs three steps: First, it performs tag mapping (TM), mapping "cost priority" in the PTV to all rules with cost constraints in the BRTL; then, it performs confidence injection (CI), multiplying the user's CS value for the tag (e.g., 0.9) by the rule's default weight (DW); finally, it initiates rule expansion (RE), automatically adding derived rules based on the device type (e.g., adding "IF SOC < 30% THEN non-interruptive" for electric vehicle charging stations). The completed Dynamic Fuzzy Rule Base (DFRB) is stored as a three-dimensional tensor: dimension 1 is the rule ID, dimension 2 is the antecedent membership function parameters, and dimension 3 is the consequent constraint boundary.

[0045] Hybrid computation of adaptive neural inference engines: The Adaptive Neuro-Inference Engine (ANIE) employs a neural-fuzzy fusion architecture. The front end is a fuzzification layer (FL), which converts precise values ​​in the DSEG (such as the current electricity price of 1.2 yuan / kWh) into fuzzy quantities. For example, when the variable "electricity price" is input, FL calls the Triangular Membership Function (TMF) to define the intervals for "low electricity price" [0.8, 1.0], "medium electricity price" [0.9, 1.3], and "high electricity price" [1.2, 1.5], calculating the membership degree (MD) of the current value to each interval. The core inference layer is implemented using a Radial Basis Function Network (RBFN): each rule corresponds to an RBF neuron, the neuron's center vector (CV) is the ideal value of the rule's antecedent (such as "high electricity price" = 1.35 yuan), and the width vector (WV) is derived from historical data statistics. When the input feature vector (including electricity price MD=0.8 and device status = "interruptible") is input, RBFN calculates the Gaussian distance (GD) between the input and each CV, and outputs the rule activation strength (RAS).

[0046] Constraint boundary generation and conflict resolution: The Consequent Layer (CL) aggregates activation rules: For rules with RAS > 0.5, it extracts their consequent constraint boundaries (e.g., "maximum power reduced by 30%"). When multiple rules conflict (e.g., rule A requires "power limit = 1kW", rule B requires "power limit = 2kW"), it initiates the Weighted Average Conflict Resolution (WACR) algorithm. WACR calculates the weighted values ​​of the constraint boundaries using RAS as the weight, for example: Rule A has a RAS of 0.7 and requires a power lower limit of 1kW; Rule B has a RAS of 0.6, requiring a power lower limit of 2kW; Therefore, the final power lower limit = (0.7×1 + 0.6×2) / (0.7+0.6) = 1.46kW.

[0047] The output Preliminary Intent Constraint Boundary (PICB) is a quadruple: Grid interaction power range: [P_min, P_max] (unit: kW); Charge / discharge time window: [T_start, T_end] (unit: minutes); Adjustable margin: ΔP (power adjustment step size); Constraint confidence level: CC (calculated using RAS).

[0048] Based on the device state evolution graph and intent constraint boundary, fine-grained intent parameters are generated through a reinforcement learning policy network; Markov decision process modeling: The energy consumption control problem is transformed into a Markov Decision Process (MDP). The State Space (SS) is defined as the topological features of the DSEG (such as average node degree and clustering coefficient) superimposed with real-time electricity prices and weather data; the Action Space (AS) is a continuous multi-dimensional vector: [power setpoint, charging / discharging start time, adjustment sensitivity]; the Reward Function (RF) contains three terms: Economic reward: R_econ = -(actual electricity cost - ideal electricity cost) × weight W1; Comfort penalty: R_comfort = -|indoor temperature change| × W2; Boundary compliance: R_boundary = -(distance of action from PICB) × W3; The weight parameters (W1, W2, W3) are dynamically adjusted by the constraint confidence CC in PICB (e.g., W3 is doubled when CC > 0.8).

[0049] Two-stream architecture of policy networks: The Reinforcement Learning Policy Network (RLPN) employs a two-stream input design: Graph Feature Flow: The adjacency matrix AM of DSEG is input into the Graph Convolution Network (GCN), which aggregates neighbor node information through three layers of GCN and outputs a Graph Embedding Vector (GEV). Constraint Feature Flow: The quadruple parameters of PICB are input to the fully connected encoder (FCE) and output a constraint embedding vector (CEV).

[0050] The dual-stream vectors are concatenated in the Feature Fusion Layer (FFL) and processed by a 128-dimensional hidden layer to output the Action Probability Distribution (APD). The network is trained using the Proximal Policy Optimization (PPO) algorithm: 10 candidate actions are generated in each round, and an environmental simulator (simulating electricity price fluctuations and equipment response) calculates the reward value. PPO updates the network parameters using the Importance Sampling Ratio (ISR).

[0051] Motion decoding and parameter generation: The action vector output by the policy network needs to be decoded into fine-grained intent parameters (FGIP): Power grid interaction: Action value [0,1] is linearly mapped to [P_min, P_max] of PICB. For example, the power corresponding to action value 0.3 is (0.3×(P_max-P_min))+P_min; Charge / discharge time window: Action value [0,1] is converted into time offset, T_start = PICB.T_start + (action value × 20 - 10) minutes (10-minute fluctuation range); Adjustable margin: ΔP = action value × PICB.ΔP_max (maximum allowable adjustment step size).

[0052] After generating parameters, perform a feasibility check: if ΔP causes the power to exceed the physical limits of the equipment (such as the maximum power of the inverter), then scale all parameters proportionally. The final output FGIP contains three dimensions and eight parameters: power setpoint (three values ​​for three time periods), center point and width of the time window, and adjustment margin gradient.

[0053] The executableness of the intent parameters is verified, conflicting schemes are filtered through the physical constraint solver, and a set of valid intent parameters is output. Multi-level constraint modeling: The Physical Constraint Solver (PCS) integrates three types of constraint models: Equipment physical constraints: battery charging and discharging power limits (e.g., 0 < P < 5kW), maximum conversion efficiency of photovoltaic inverter (η_max = 98%). Power grid interaction constraints: upper limit of transformer capacity in the distribution area (e.g., 100kVA), voltage fluctuation threshold (±5%). User behavior constraint: Based on the probability distribution of travel time and the room temperature comfort zone [22°C, 26°C] from historical data; The constraint is transformed into a mathematical expression: For example, the battery SOC change rate dSOC / dt = (η_charge × P_charge - P_discharge / η_discharge) / Capacity, and it is required that 0.2 < SOC < 0.9.

[0054] Conflict detection and relaxation optimization: After inputting the FGIP into the constraint solver, start the Mixed Integer Programming (MIP) engine: Hard conflict detection: Check whether the uncompromising constraints are violated (such as P_set > the maximum power of the device). If a conflict is detected, mark this parameter group as "Invalid" (Invalid Flag, IF = 1); Soft constraint relaxation: For tolerable constraints (such as a temporary over - standard room temperature), calculate the violation metric (ViolationMetric, VM). For example, if the actual power P causes the transformer load rate L = 105%, then VM=(L - 100%) / 5% = 1.0.

[0055] Adopt the Elastic Constraint Method (ECM): Add a relaxation variable S_i for each soft constraint, and minimize the total penalty value of the objective function min Σ(S_i × Penalty_Weight). For example, for the room temperature constraint 22 < T < 26, after adding relaxation, it becomes 22 - S1 < T < 26 + S2, and the objective is min(10×S1 + 10×S2) (the weight 10 represents the penalty per degree deviation).

[0056] Pareto front screening: The FGIP with constraints enters the Multi - Objective Optimization Layer (MOOL). Taking three optimization objectives as an example: Objective 1: Minimize the electricity cost (Economic Cost, EC); Objective 2: Minimize the equipment wear (Wear Cost, WC); Objective 3: Maximize the boundary compliance (Boundary Compliance, BC).

[0057] A Pareto Solution Set (PSS) is generated using a non-dominated sorting genetic algorithm (NSGA-II). Each solution is assigned a composite score (CS) = w1×(1-EC_norm) + w2×(1-WC_norm) + w3×BC_norm, with weights w_i determined by the user's PTV. The final output is a Valid Intent Parameter Set (VIPS), consisting of the top 3 solutions ranked by CS, stored as a 3×8 matrix (3 sets of parameters × 8 parameter values).

[0058] The effective intent parameter set is encoded into an energy consumption intent vector, encrypted using the lightweight national cryptographic algorithm SM4, and the encrypted fine-grained energy consumption intent vector is output.

[0059] Parameter encoding and vector structuring: In VIPS, each set of parameters first undergoes normalization encoding (NE): mapping the actual value to the integer range [0, 255]. For example, if the power setting is 5kW and the maximum power of the device is 10kW, then the encoded value = round(5 / 10 × 255) = 128. Next, differential encoding (DE) is performed: the second set of parameters stores the difference between it and the first set, and the third set stores the difference between it and the second set. For example: Group 1 time window center = 14:00 → Coded value C1; Group 2 time window center = 14:15 → Store ΔC = C2 - C1.

[0060] The final raw intent vector (RIV) is a 48-byte sequence: the first 16 bytes are header information (including version number and device ID), the middle 24 bytes store three sets of parameters, and the last 8 bytes are the checksum (CS).

[0061] SM4 encryption process (Chinese national standard): Encryption is performed using the lightweight Chinese national cryptographic algorithm SM4. Key generation: A 128-bit key KEY is generated using the user terminal's unique hardware identifier (such as the CPU serial number) through the Key Derivation Function (KDF). Initial vector preparation: Take the last 128 bits of the current timestamp as the initial vector IV.

[0062] Round function processing: The 48-byte RIV is split into three 16-byte blocks, and each block undergoes 32 rounds of encryption. XOR the input block with the key. After S-box nonlinear substitution (SS); Perform linear transformations L: Left Rotate (LR) and Modular Addition (MA).

[0063] The output of each round serves as the input for the next round, ultimately resulting in a Ciphertext Block (CB). Three CBs are concatenated to form a 48-byte Encrypted Intent Vector (EIV).

[0064] Integrity protection and output: Add a Message Authentication Code (MAC) to the EIV: Calculate a 32-bit MAC value using the KEY via the HMAC-SM3 algorithm; The MAC is appended to the end of the EIV to form a complete 80-byte data packet.

[0065] Before output, side-channel resistance (SCR) is performed: random No-Operation (NOP) instructions are inserted to disrupt power timing. The final encrypted fine-grained energy consumption intent vector includes: Encryption parameter body: 48 bytes; MAC value: 4 bytes; Protocol version: 2 bytes; Timestamp: 8 bytes; Terminal signature: 18 bytes.

[0066] A total of 80 bytes of standardized output is transmitted to the network encapsulation layer via a secure bus.

[0067] S203, the fine-grained energy consumption intent vector is encapsulated into a structured, standardized intent expression data packet, and broadcast to neighboring energy nodes and the regional energy coordinator via a point-to-point network; Specifically, it can parse fine-grained energy consumption intent vectors, construct intent metadata headers, and output a structured intent description framework; Intent vector parsing and metadata header construction: Once the lightweight edge AI model on the user terminal side generates the Fine-grained Energy Intent Vector (FEIV), this vector contains specific parameters such as encrypted grid interaction power (GIP, unit: kilowatts), charging / discharging time window (CDTW, format: start timestamp to end timestamp), and adjustable margin (AM, unit: percentage). The system first parses the FEIV, that is, disassembles its internal structure. The parsing process identifies the semantics of each field in the vector: for example, bytes 1-4 of the vector store the floating-point value of GIP, bytes 5-12 store the 64-bit time encoding of CDTW, and bytes 13-16 store the fixed-point value of AM. Based on this, the system constructs the Intent Metadata Header (IMH). IMH is a fixed-length data structure (e.g., 128 bytes) containing key descriptive information: Data Version Number (DVN, e.g., V1.2 identifies the protocol version), Data Type Label (DTL, fixed as "EnergyIntent"), Priority Identifier (PID, mapped to an integer value from 0 to 255 based on the "priority label" in the user's preset fuzzy preference statement), Generation Timestamp (GTS, UTC time accurate to milliseconds), and Vector Length Checksum (VLC, used for subsequent tamper-proof verification). The purpose of IMH is to add self-descriptiveness to the original intent vector, enabling the receiver to quickly understand the data content without relying on an external dictionary.

[0068] The logic for generating structured frameworks: The essence of building a Structured Intent Description Framework (SIDF) is to standardize the logical relationship between the IMH and FEIV. SIDF adopts a layered design: Header Layer (IMH): This serves as the index directory for the framework. For example, a PID value of 128 indicates that the intent belongs to the "economy priority" category, allowing the coordinator to quickly filter matches.

[0069] Body Layer: Reserves a pointer field (PF) to the FEIV, declaring the storage offset of the FEIV in the data packet (e.g., starting from byte 0 after the IMH ends).

[0070] Extension Layer: Contains optional fields, such as Device Type Code (DTC, e.g., "ES" for energy storage system, "PV" for photovoltaic inverter), for targeted processing by the receiver.

[0071] After the framework is generated, the system performs logical verification: it checks whether the VLC in the IMH is consistent with the actual length of FEIV (for example, if FEIV is 256 bytes long, then VLC = 256 CRC16 checksum). If they are inconsistent, an error regeneration process is triggered. The output SIDF is a binary stream, ensuring that it has cross-platform parsing capabilities.

[0072] The intent description framework is bound to a fine-grained energy-consuming intent vector, and intent expression data packets are generated through TLV encoding. Physical binding between frames and vectors: The binding process combines SIDF and FEIV into a contiguous memory block. Specific operations: Allocate memory space and write the header to the complete binary stream of SIDF (e.g., 128 bytes). Immediately following SIDF, write the raw FEIV data (e.g., 256 bytes).

[0073] A delimiter identifier (DI, a fixed 2-byte 0xFFFF) is inserted between the two to prevent boundary confusion during parsing.

[0074] After binding, a raw data block (RDB) is formed. At this point, the RDB has complete semantics: the receiver can read the PF field in the SIDF (e.g., value = 128) to locate the start position of FEIV (SIDF start address + 128 bytes), and verify the correctness of the location by combining it with DI.

[0075] TLV encoding enables standardized encapsulation: To standardize the data exchange format between heterogeneous systems, TLV (Type-Length-Value Encoding) is used to convert RDB into Intent Expression Data Packets (IEDP). The TLV encoding rules are as follows: The Type field (T, 2 bytes): Defines the data type. In this example, it is fixed at 0x4E49 (ASCII "NI", representing "Networked Intent"). Length field (L, 4 bytes): Records the byte length of the Value part (e.g., RDB length = 128 + 256 + 2 = 386 bytes, then L = 386). Value field (V, variable length): Stores the entire contents of the RDB directly.

[0076] During encoding, the system writes the T, L, and V fields sequentially to contiguous memory. For example: Bytes 0-1: 0x4E49(T); Bytes 2-5: 0x00000182 (hexadecimal L=386); Bytes 6-391: RDB (including SIDF+DI+FEIV).

[0077] This encoding ensures that the packet structure is self-contained: after the receiver reads the T field to confirm the type, it accurately extracts the content of the V field based on the L field, and then parses the internal structure using SIDF. TLV's resistance to parsing errors is significantly better than that of plain text protocols (such as JSON), making it particularly suitable for low-bandwidth energy IoT scenarios.

[0078] Add a lightweight blockchain identity signature to the intent expression data packet to generate a standardized data packet with authentication; Blockchain identity signature mechanism: Each energy node is assigned a unique blockchain identity (BID) upon registration, which includes: Private Key (PriK): Securely stored by the node and used to generate signatures; Public Key Address (PKA): A publicly disclosed 26-character string (such as "0x3F5A...C7D9") that serves as an identity identifier.

[0079] Once the IEDP is generated, the system uses a lightweight signature algorithm (lightweight means low computational overhead, such as the ECDSA-secp256r1 elliptic curve algorithm) to sign it: Calculate the hash digest (HD) of the IEDP: Use the SHA-256 algorithm to generate a 32-byte unique fingerprint (e.g., input 386 bytes of IEDP, output a fixed 32-byte HD).

[0080] Digital Signature (DS) of HD using the node's PriK: Generate 64 bytes of signature data (e.g., 32 bytes of r value + 32 bytes of s value) through elliptic curve multiplication.

[0081] Standardized data packet encapsulation: Combine the signature information with the original IEDP to form an Authenticated Standardized Packet (ASP): Header: Writes a 4-byte magic number (MN, fixed at 0x454E4552, i.e., the hexadecimal representation of "ENER") to help the receiver quickly identify the data packet type; Identity field: Writes the node's PKA (26 bytes); Signature segment: Write to DS (64 bytes); Data segment: Write the raw IEDP (containing complete data encoded in TLV).

[0082] For example, the ASP structure: Bytes 0-3: MN=0x454E4552; Bytes 4-29: The binary format of PKA="0x3F5A...C7D9"; Bytes 30-93: DS (64 bytes); Bytes 94-479: IEDP (386 bytes).

[0083] The final total length of the ASP is fixed at 480 bytes (4+26+64+386). This fixed-length header plus variable-length body design balances parsing efficiency and flexibility. After receiving the ASP, any node can find the sender's public key through PKA, recalculate the HD of the IEDP using the same SHA-256 algorithm, and then verify whether the DS matches using the public key, thereby confirming the authenticity and integrity of the data source.

[0084] Based on a geographic location hash table, nearby energy nodes are selected, and standardized data packets are broadcast to nearby energy nodes and the regional energy coordinator via a low-latency P2P protocol.

[0085] Dynamic neighbor node selection strategy: The system maintains a Geohash Location Table (GLT), the core of which is to map physical locations to grid codes. Each node periodically broadcasts its latitude and longitude coordinates (e.g., longitude 116.407°E, latitude 39.904°N) and network address (e.g., IP:Port).

[0086] The receiving node uses the Geohash algorithm (a spatial indexing algorithm that encodes two-dimensional coordinates into strings) to convert the coordinates into a 9-character string (e.g., "wx4g0b"), which implicitly contains a grid area with an accuracy of about 5 meters.

[0087] Nodes store a list of network addresses of all active nodes in their local GLT (e.g., a list ["192.168.1.2:5683", "10.0.0.5:5683"]) of neighboring grids (e.g., grids with the same first 6 characters).

[0088] When it is necessary to broadcast an ASP, the sending node executes: Query its own Geohash value (e.g., "wx4g0b").

[0089] Retrieve all Neighbor Geohash Keys (NGK) in GLT, i.e., keys that match the first 6 characters (such as "wx4g0b", "wx4g0c", etc.).

[0090] The lists of node addresses corresponding to these keys are merged to form a Proximate Node Set (PNS). Simultaneously, the fixed address of the Regional Energy Coordinator (REC) (e.g., "coordinator.energy-grid:5683") is forcibly added to the PNS. Addresses of the user themselves are excluded during the filtering process to prevent loopback transmission.

[0091] Low-latency P2P broadcast execution: Broadcasting can be performed using low-latency P2P protocols (such as the UDP-based CoAP protocol, CoAP = Constrained Application Protocol, a lightweight transport protocol designed specifically for the Internet of Things). Packet fragmentation: If the ASP exceeds the CoAP single packet limit (usually 1024 bytes), it is fragmented into multiple fragment packets (FP) with a 1280-byte MTU. Each FP carries the fragment sequence number and the total number of fragments.

[0092] Neighbor discovery: A Neighbor Discovery Request (NDR) is sent via a CoAP multicast address (e.g., IPv4 224.0.1.187). Nodes in the GLT respond to the NDR to confirm their online status.

[0093] Reliable broadcasting: Employing an epidemic routing strategy. The sending node unicasts an ASP (or FP sequence) to each address in the PNS. If the receiving node receives new data, it will continue to forward it to its neighbors in its own GLT (the number of hops is limited to 3 to prevent network storms).

[0094] Coordinator direct access: Establishes a reliable transport connection to the REC address separately (e.g., CoAP over DTLS) to ensure that critical commands are delivered.

[0095] The entire process completes the broadcast coverage of all nodes within a 500-meter radius within 200 milliseconds. The latency metric is recorded in the ASP using timestamp synchronization (TS, with an accuracy of 0.1 milliseconds) to record the transmission time, allowing the receiver to calculate the transmission delay.

[0096] S204, at the regional energy coordinator, the received intent expression data packets from multiple nodes are aggregated, and based on the preset consensus rules, intent compatibility verification and secure interaction matching are performed to generate an encrypted interaction confirmation instruction set containing the matching node pairs and their interaction terms. Specifically, the regional energy coordinator can receive intent expression data packets from multiple nodes, verify identity signatures through zero-knowledge proofs, and output a set of trusted nodes and their intent expression data packets. The Regional Energy Coordinator (REC), serving as the core hub of the regional energy network, is deployed on a server cluster with high computing power and robust security. Its gateway continuously listens to the peer-to-peer (P2P) network port, receiving Intention Expression Packets (IEPs) broadcast from distributed energy nodes (such as residential solar PV users, energy storage stations, and electric vehicle charging stations). Each IEP contains three core components: a structured intent description framework (describing user identity and intent type), a fine-grained energy consumption intent vector (encrypted grid interaction parameters), and a lightweight blockchain identity signature (identity credentials based on asymmetric encryption). The REC first activates the Packet Aggregation Engine (PAE), which employs multi-threaded parallel technology to cache and queue hundreds of simultaneously arriving IEPs, sorting them by their received timestamp (TS). To prevent flooding attacks from malicious nodes, PAE has a built-in Traffic Shaping Module (TSM) that uses the Token Bucket Algorithm (TBA) to limit the packet submission rate of a single node per unit time. For example, each node can submit a maximum of 5 IEPs per second. Packets exceeding this limit will be temporarily discarded and an alarm log (AL) will be recorded.

[0097] The aggregated IEP enters the Zero-Knowledge Proof Verification Layer (ZKPVL). The goal of this verification is to confirm the authenticity of the Blockchain Identity Signature (BIS) in the data packet without exposing the node's private key (PK). The system employs a non-interactive zero-knowledge proof protocol (NIZKP), such as zk-SNARKs (Succinct Non-interactive Argument of Knowledge). Specifically, the verifier generates a random challenge value (CV) based on the node's public key (PUK) and signature algorithm identifier (e.g., ECDSA-secp256k1) carried in the IEP. The proof (PF) computed locally by the node using its private key PK and the IEP content is pre-loaded into the BIS. ZKPVL calls the Verify Function (VF), taking CV, PF, PUK, and the IEP hash value (HV) as input. If the output is "True," it proves that the node legitimately possesses the private key and has not tampered with the data packet content. For example, after the IEP of a photovoltaic node A passes verification, its public key PUK_A and the complete IEP are marked as trusted. IEPs that fail verification (such as those with forged signatures or corrupted content) will be isolated to a sandbox for in-depth analysis, triggering a Security Incident Response (SIR).

[0098] The IEP verified by ZKPVL and its associated node information (node ​​ID, geographic location, public key) are input into the Trusted Node Set Generator (TNSG). TNSG maintains a dynamic Trusted Node List (TNL), employing a Least Recently Used (LRU) strategy to manage memory and prevent list bloat. Each trusted node's IEP is parsed into an internal data structure: a structured intent description framework is converted into a JSON object (JavaScript Object Notation), the encrypted energy consumption intent vector remains in ciphertext, and the signature verification result is appended with a timestamp. Finally, TNSG outputs a Trusted Node Set (TNS) and its corresponding Trusted Intent Expression Data Packet (TEP, TIEP). TNS is stored in a Secure Enclave (SE), accessible only to subsequent modules through authorized interfaces, ensuring data isolation. For example, if REC aggregates 50 node IEPs during a certain period, of which 45 are verified, TNS contains the IDs of these 45 nodes and their TIEP sets, providing clean input for subsequent compatibility analysis.

[0099] Deconstruct the intent expression data packet to extract power grid interaction power and time window parameters, and construct a multi-dimensional intent compatibility matrix; TIEP then enters the Intention Deconstruction Module (IDM). This module first processes the structured intent description framework (JSON format) and extracts key metadata: Node Type (NT, such as "photovoltaic" or "energy storage"), Intention Operation (IO, such as "electricity sales" or "electricity purchase"), and Protocol Version (PV). Next, it decrypts the encrypted Fine-Grained Energy Intention Vector (FGEIV). REC deploys a dedicated Hardware Security Module (HSM), which pre-installs a Decryption Key (DK) for the SM4 national cryptographic algorithm. HSM operates in physical isolation. The decrypted FGEIV contains plaintext parameters: Grid Interaction Power (GIP, in kilowatts, including maximum / minimum values), Charging / Discharging Time Window (CDTW, such as start timestamp TS_start, end timestamp TS_end), and Adjustable Margin (AM, such as power adjustable by 10%). For example, the decrypted FGEIV of a certain energy storage node shows: GIP_min = -5kW (discharging), GIP_max = 3kW (charging), CDTW is 14:00-16:00, and AM = 15%.

[0100] The deconstructed parameter input is used by the Multi-Dimensional IntentionCompatibility Matrix Builder (MDICMB). This builder defines three core dimensions: Power Compatibility Dimension (PCD): Calculate the intersection of the power sales range of node A (e.g., -10kW to 0kW) and the power purchase demand of node B (e.g., 0kW to 5kW). If the intersection is not empty (e.g., A can provide -5kW, B needs +3kW), it is marked as compatible (Compatibility Flag, CF=1).

[0101] Time Window Compatibility Dimension (TWCD): Compares the overlap duration (OD) between the CDTW of node A (e.g., 13:00-15:00) and the CDTW of node B (e.g., 14:00-16:00). If the OD is greater than a threshold (e.g., 15 minutes), it is marked as compatible (CF=1).

[0102] Adjustment Margin Compatibility Dimension (AMCD): Evaluate whether the AM of node A (e.g., an increase of 10%) can cover the power fluctuation tolerance of node B (e.g., ±8%). If it can cover the tolerance, it is marked as compatible (CF=1).

[0103] MDICMB generates a three-dimensional compatibility vector (CV) for each pair of nodes (A, B). For example, (PCD=1, TWCD=1, AMCD=0) indicates power and time compatibility but mismatched adjustment margins. The CVs of all node pairs are organized into a Multi-Dimensional Intention Compatibility Matrix (MDICM). This matrix is ​​a sparse matrix, using a compressed storage format (e.g., CSR-Compressed Sparse Row) to optimize memory. The matrix row / column indices correspond to the node IDs, and the cells store the CV and a snapshot of the original parameters (e.g., GIP range, CDTW). Simultaneously, MDICMB calculates the Global Supply-Demand Balance Index (GSDI), such as the ratio (R=0.9) of total electricity sales capacity (-200kW) to total electricity purchase demand (+180kW) within a region. If R∈[0.95,1.05], the region is considered balanced. MDICM and GSDI together constitute the input for subsequent consensus verification.

[0104] Input the compatibility matrix into the consensus engine based on Byzantine fault tolerance to verify the supply and demand balance constraints among nodes and output a candidate set of matching node pairs. MDICM and GSDI were submitted to the Byzantine Fault-Tolerant Consensus Engine (BFTCE). This engine employs an improved Practical Byzantine Fault-Tolerant (PBFT) algorithm, optimized for energy scenarios as Low-Latency Asynchronous (LA-BFT). BFTCE consists of multiple REC replicas within a region, for example, four replicas (R1 master node, R2-R4 slave nodes). The master replica R1 partitions MDICM into a sub-matrix (SM), which is then distributed among the replicas for parallel processing. Each replica's local validator (LV) performs two core operations: Supply-Demand Constraint Validation (SDCV): Examines the difference (Delta, Δ) between the total demand (∑Demand) of the purchasing nodes and the total supply (∑Supply) of the selling nodes within the submatrix. If |Δ| ≤ the global threshold (e.g., 5kW), the validation passes (Validation Result, VR=Pass).

[0105] Malicious Node Detection (MND): Based on historical interaction reputation score (RS) and the reasonableness of current parameters (such as whether the GIP exceeds the device's nameplate power), suspicious nodes are marked. For example, if a node claims to be able to sell 100kW of electricity, but its photovoltaic inverter has a rated power of only 50kW, it is marked as an anomaly (AF=1).

[0106] After each copy completes local verification, it enters the three-phase consensus protocol: Pre-Prepare Phase: The primary replica R1 broadcasts a pre-prepare message (PPM) containing the MDICM hash (Hash_H) and the verification result (such as VR=Pass, AF={node5}).

[0107] Prepare Phase: After receiving the PPM from the replica, verify the consistency between Hash_H and the locally calculated result. If they are consistent and the conclusion is accepted, broadcast a Prepare Message (PM). When a replica receives 2f+1 valid PMs (f is the maximum number of fault-tolerant replicas, here f=1), it enters the next phase.

[0108] Commit Phase: Replicas broadcast commit messages (CM). After receiving 2f+1 valid CMs, they write the verification results to the local ledger (LL).

[0109] After consensus is reached, BFTCE triggers the Matched Node Pair Generator (MNPG). Based on the validated MDICM, MNPG employs the Weighted Bipartite Matching Algorithm (WBMA). Sellers form the left set (LS), and buyers form the right set (RS). Edge weights are calculated using the Compatibility Score (CS) from the Compatibility Vector (CV), with the formula: CS = α×PCD + β×TWCD + γ×AMCD (where α, β, and γ are adjustable weight coefficients). WBMA uses the Kuhn-Munkres algorithm (KM algorithm) to solve for the Maximum Weight Matching (MWM). For example, node A (Seller) and node B (Buyer) are matched because CS = 0.85, and node C (Seller) and node D (Buyer) are matched because CS = 0.92. The final output is a Matched Node Pair Candidate Set (MNPCS), in the format {(A,B), (C,D), ...}, along with a draft of the interaction terms for each match (such as transaction volume and time window).

[0110] The matching nodes perform a security assessment on the candidate set, verify the authenticity of the data through privacy-preserving calculations, and generate a risk scoring matrix. MNPCS enters the Security Assessment Engine (SAE). The core task of the SAE is to verify the authenticity of data between matched node pairs (e.g., whether the electricity seller truly has surplus electricity) while protecting the privacy of the original data. For this purpose, Privacy-Preserving Computation (PPC) technology is employed, specifically Secure Multi-Party Computation (SMPC). For example, for a matched pair (A, B): Node A (the electricity seller) has private time-period generation forecast data (GFD_A).

[0111] Node B (the electricity purchaser) has private load profile data (LPD_B).

[0112] Both parties need to verify: Is A's GFD_A sufficient to cover its committed electricity sales? Does B's LPD_B match its electricity purchase declaration? However, neither party is willing to disclose the original data.

[0113] The SMPC process is as follows: Secret Sharing (SS): A splits GFD_A into two fragments (Share1_A, Share2_A), and B splits LPD_B into (Share1_B, Share2_B). The fragments are sent to two non-colluding computing parties (NCCP1, NCCP2) via an obfuscated channel.

[0114] Collaborative Computing (CC): NCCP1 receives Share1_A and Share1_B, and NCCP2 receives Share2_A and Share2_B. Both execute predefined functions for computation. Verify A's electricity sales capacity: GFD_A - A's self-consumption ≥ Promised electricity sales volume? Verify B's electricity purchase demand: LPD_B - B's self-generated electricity ≥ Declared electricity purchase amount? Result Reconstruction (RR): NCCP1 and NCCP2 send fragments of their respective computation results (Boolean values ​​True / False) back to REC. REC reconstructs the final verification result (Verification Result, VR), but cannot obtain the original GFD_A or LPD_B.

[0115] Based on SMPC's VR and other risk indicators (such as node historical default rate and communication latency), SAE constructs a Risk Scoring Matrix (RSM). Rows in the matrix correspond to matching node pairs, and columns define risk dimensions. Data Authenticity Risk (DAR): When the SMPC verification result is False, DAR = High Risk (HR).

[0116] Node Reputation Risk (NRR): Based on the historical default records (DR) stored on the blockchain, if DR ≥ 3 times, then NRR = HR.

[0117] Cyber ​​Attack Risk (CAR): Based on Intrusion Detection System (IDS) alerts, if there has been a recent Denial-of-Service (DoS) attack targeting a node, then CAR=HR.

[0118] The risk level (RL) of each dimension is quantified into a numerical value (e.g., 0-10 points), and the weighted sum is used to obtain the total risk score (TRS). For example, the TRS of the matching pair (A,B) is w1×DAR + w2×NRR + w3×CAR = 2.3 (low risk).

[0119] Based on the risk scoring matrix and the interaction terms template, an encrypted interaction confirmation instruction set is generated.

[0120] RSM and MNPCS Input Interaction Clause Generator (ICG). The ICG includes a built-in Clause Template Library (CTL) containing a standardized energy interaction protocol framework. Core Clause: Traded Energy (TE, unit kWh), Power Profile (PP), Time Window (TW), Settlement Price (SP).

[0121] Fault Tolerance Clause: Power Deviation Tolerance (PDT, e.g., ±5%), Delay Compensation (DC).

[0122] Penalty Clause: Penalty Calculation Rule (PCR).

[0123] For example, a photovoltaic power sales template might stipulate: SP = real-time electricity price × discount factor 0.9, PDT = ±8%, DC = if the delay exceeds 10 minutes, the fee will be deducted proportionally.

[0124] ICG instantiates a template for each matching node pair: Extract matching parameters from MNPCS (e.g., A sells electricity to B, TE=15kWh, TW=14:00-15:00).

[0125] According to RSM's TRS adjustment terms: if TRS > threshold (e.g., 7.0), additional guarantee terms (e.g., advance payment of margin) are added.

[0126] Embedded dynamic pricing factor: If GSDI shows a supply shortage (R>1.05), the SP will be automatically increased.

[0127] Finally, a plaintext Interaction Clause (IC) is generated, such as: "Node A sells 15kWh of electricity to Node B from 14:00 to 15:00 at a unit price of 0.5 yuan / kWh, with a power deviation tolerance of ±5%, and a penalty for breach of contract = unfulfilled quantity × unit price × 200%".

[0128] The plaintext IC is fed into the Encrypted Instruction Set Assembler (EISA). EISA executes: Instruction structuring: Convert ICs into machine-readable JSON instructions (JSON Instruction, JI), and add instruction ID (Instruction ID, IID), effective time (Effective Time, ET), and digital digest (Digital Digest, DD).

[0129] Asymmetric encryption: JI is encrypted using the public key of the receiving node (such as PUK_B of B) to generate a ciphertext instruction (CI).

[0130] Instruction set packaging: Generate an independent Encrypted Interaction Confirmation Instruction (EICI) for each matching pair (A,B), in the format {EICI_ID, IID, Receiver ID, CI}.

[0131] All EICIs constitute an Encrypted Interaction Confirmation Instruction Set (EICIS). After attaching a timestamp (TS) and a regional coordinator signature (REC Signature, REC_Sig) to the EICIS, it is ready to be distributed to the matching node. For example, an EICI might look like this: {EICI_ID="TX20240411001", IID="CL2024041101", Receiver ID="Node_B", CI="sm2p256v1_encrypted_data"}.

[0132] S205, the encrypted interaction confirmation instruction set is distributed to the relevant matching nodes, triggering automated, point-to-point energy data flow interaction and execution between nodes based on the interaction terms, and simultaneously synchronizing the key summary information of the execution result to the blockchain network for tamper-proof storage.

[0133] Specifically, a secure group key distribution mechanism can be used to push encrypted interaction confirmation instruction sets to matching node pairs. Once the regional energy coordinator generates an Encrypted Interaction Confirmation Instruction Set (EICIS) containing matching node pairs (e.g., user A's energy storage station and user B's electric vehicle) and their interaction terms (e.g., A transmitting 5kW of electricity to B during the period 14:00-15:00), the primary task is to securely distribute the instructions to the relevant nodes. This relies on the Secure Group Key Distribution Mechanism (SGKDM). This mechanism first dynamically generates a unique Temporary Session Key (TSK) for each matching node pair, for example, using a 256-bit key based on Elliptic Curve Cryptography (ECC-256). The coordinator completes the key distribution through a pre-configured Trusted Execution Environment (TEE) on the nodes: the coordinator encrypts the TSK using the target node's Long-term Public Key (LPK) to form a Key Distribution Packet (KDP). For example, user A's KDP contains a TSK encrypted with A's LPK, and user B's KDP contains the same TSK encrypted with B's LPK. All KDPs, together with EICIS (which is itself encrypted with the coordinator's master key), constitute a Directed Delivery Package (DDP).

[0134] The push process employs a Multi-path Redundant Transmission Protocol (MRTP) to ensure reliability. The coordinator selects three independent communication paths (e.g., cellular network, LoRaWAN, and local Wi-Fi Mesh) for each target node based on the network topology map. The Data Attached Packet (DDP) is split into multiple data fragments (DF), each fragment is appended with an error correction code (such as Reed-Solomon encoding), and then transmitted in parallel through different paths. The node-side Secure Communication Agent (SCA) continuously monitors each path, immediately reassembling the DDP fragments upon receiving the first complete set, and discarding subsequent redundant fragments. For example, user node A's SCA receives 60% of the fragments via the cellular network, 30% via LoRaWAN, and 10% via the Mesh, completing reassembly within 200 milliseconds (ms). After reassembly, SCA calls the Asymmetric Decryption Engine (ADE) within the TEE, uses the node's private key (PRK) to decrypt the KDP to obtain the TSK, then uses the TSK to decrypt the EICIS, and finally restores the plaintext interaction commands within the TEE's secure area.

[0135] To defend against man-in-the-middle attacks, the mechanism introduces Two-Factor Key Confirmation (TFKC). After decrypting EICIS, a node must send a random challenge code (RCC, such as a 128-bit random number) encrypted with TSK to the coordinator. The coordinator decrypts the RCC using the same TSK and compares it with the original value. If they match, the coordinator replies with a Confirmation Signature (CSIG). Only after receiving the CSIG and verifying the coordinator's digital signature does the node officially activate the interaction command. The entire process is completed within 3 seconds. If a node fails to respond within the timeout period (e.g., due to network failure), the coordinator initiates the Backup Node Replacement Procedure (BNRP), selecting a suboptimal node from the candidate matching set to redistribute the command.

[0136] After receiving the encrypted interaction confirmation instruction, the matching node automatically decrypts it, triggers the smart contract to parse the interaction terms, and outputs control instructions for the energy data stream. Upon receiving plaintext interaction instructions within the TEE, the node immediately triggers the pre-deployed EnergyInteraction Smart Contract (EISC). This contract takes an Interaction Clause (IC) as input, and the IC is described using a standardized structure, for example: { "source": "Node_A_ESS", / / Source node identifier (User A's energy storage system) "target": "Node_B_EV", / / Target node identifier (User B's electric vehicle) "power": {"value": 5.0, "unit": "kW"}, / / Interactive power "time_window": {"start": "2025-04-11T14:00:00Z", "end": "2025-04-11T15:00:00Z"}, / / Time window "penalty_terms": {"overdraw": 0.2, "underdraw": 0.1} / / Penalty coefficient for breach of contract } The Contract Parsing Engine (CPE) first verifies the IC format compliance, rejecting illegal fields (such as negative power values). After successful verification, the CPE extracts key parameters and converts them into device-operable instructions.

[0137] The parsed parameters are input into the Control Instruction Generation Module (CIGM). This module, combined with local device status (such as the remaining capacity of the energy storage system and the type of electric vehicle charging interface), generates specific Energy Data Flow Control Instructions (EDFCI). For example: User A's energy storage system command: { "action": "discharge", "target_power": 5.0kW, "duration": 3600s, "grid_export_limit": 0kW}; User B's electric vehicle command: { "action": "charge", "target_power": 4.8kW, "voltage_range": 380V±5%, "max_charge_time": 3600s}.

[0138] The value of 4.8kW (instead of 5kW) is an optimized value reserved for line losses. The instruction generation process calls the Local Policy Library (LPL), such as the policy of prioritizing energy storage discharge over grid purchase (Policy ID: POL-ESS-001).

[0139] To ensure command executability, the module performs a Physical Constraint Real-time Check (PCRC). For example, if user A's energy storage system has a remaining capacity of 40 kWh instantaneously before command execution and plans to discharge 5 kW × 1 h = 5 kWh, the check passes. If the remaining capacity is only 3 kWh, instruction renegotiation (IR) is triggered: an adjustment request (e.g., reducing to 3 kW) is sent to the coordinator, which then re-matches and distributes the new command. After all checks pass, the EDFCI is signed and sent to the device controller (such as the energy storage converter or electric vehicle charging station).

[0140] Point-to-point energy interaction is executed based on control commands, and key indicators including power and timestamps are collected in real time to generate execution summary metadata. After receiving the EDFCI, the device controller initiates the Peer-to-Peer Energy Interaction Protocol (P2P-EIP). The source node (User A) and the target node (User B) first establish a direct communication link (such as an energy service interface based on the IEEE 2030.5 protocol) and negotiate interaction parameters (IP). For example: Communication channel: Dedicated frequency band 868MHz (LoRa modulation); Data sampling rate: 1 time / second (1Hz); Power control accuracy: ±0.5%; Both controllers synchronize atomic clocks (error <1ms) and align timestamps (TS) based on Coordinated Universal Time (UTC).

[0141] During energy transmission, the high-precision metering units (HPMUs) built into both devices collect key indicators in real time: Instantaneous Power (IPW): For example, user A outputs 4.98kW and user B inputs 4.75kW; Accumulated Energy (ACE): For example, 4.82 kWh was transferred at 15:00. Voltage / current harmonic distortion (THD): e.g., voltage THD < 3%; Timestamp (TS): accurate to milliseconds (ms), such as 2025-04-11T14:30:15.234Z.

[0142] Data is embedded with power signals (such as power line carriers) via in-band transmission (IBT) to ensure that power is synchronized with the data stream.

[0143] After the interaction is complete, the Summary Generator (SG) compiles and executes the summary metadata (ESM) according to a preset template: { "tx_id": "TX-20250411-1428", / / Interactive Transaction ID "actual_power": 4.82, / / Actual transmitted energy (kWh) "avg_power": 4.79, / / Average power (kW) "time_deviation": 1.2, / / Time window deviation (seconds) "thd_v": 2.1, / / Voltage harmonic distortion rate (%) "penalty_calc": 0.0, / / Penalty for breach of contract "signature": "0x9A3F..." / / Digital signature of both nodes } The time deviation is calculated as |actual end time - protocol end time|. In this example, the penalty clause was not triggered for 1.2 seconds (threshold 5 seconds).

[0144] The execution digest metadata is submitted to the blockchain network, and immutable evidence is stored through a practical Byzantine consensus algorithm.

[0145] After generating the ESM, nodes submit it to the Consortium Blockchain Network (CBN), a network specifically designed for energy trading, via a Blockchain Adapter (BCA). The submission process involves three steps: Data formatting: ESM is converted into an on-chain compatible structure (such as Protobuf encoding); Additional identity credentials: Add a node digital certificate (DC); Payment of transaction fuel fee: deducting the gas tokens (Gas Token, GT, e.g., 0.001 GT) in the pre-deposited on-chain account. The data packet is initially screened by the entry node (EN) and then broadcast to the entire network.

[0146] The network uses the Practical Byzantine Fault Tolerance (PBFT) algorithm to achieve consensus. Assume the network has N=4 validator nodes (VN), including: VN1: Regional power grid operator; VN2: Energy Exchange; VN3: User Representative Committee; VN4: Third-party auditing firm.

[0147] The consensus was reached in three rounds: Pre-prepare phase: The primary VN (in rotation) broadcasts the ESM packet to other VNs; Preparation phase: Each VN verifies the validity of the data (such as signature and format) and broadcasts confirmation; Commit phase: After receiving 2N / 3=3 confirmations, VN writes ESM into a new block.

[0148] Once the notarization is completed, a Blockchain Receipt (BR) is generated, which includes: Transaction Hash (TXH): e.g., 0x5a3b...c89d; Block height (BH): e.g., #782346; Time Proof (TSP): On-chain timestamp (error < 500ms); Notarization Status (NS): Success.

[0149] The receipt is pushed back to the relevant node via event. If consensus fails (e.g., tampering is detected), Notarization Dispute Resolution (NDR) is triggered: the ESM is forwarded to the arbitration smart contract, which calls an off-chain oracle to verify the original device logs and then makes a ruling. The entire process is completed within 15 seconds, and the data is permanently stored in the distributed ledger.

[0150] As can be seen, the system receives encrypted raw operating data and fuzzy energy consumption preference declarations, extracts real-time physical state feature vectors of local devices based on the raw operating data, performs localized energy consumption intent reasoning based on the real-time physical state feature vectors and fuzzy energy consumption preference declarations, and generates fine-grained energy consumption intent vectors. These fine-grained energy consumption intent vectors are then encapsulated into intent expression data packets. At the regional energy coordinator, the received intent expression data packets from multiple nodes are aggregated to generate an encrypted interaction confirmation instruction set. This encrypted interaction confirmation instruction set is then distributed to relevant matching nodes, triggering energy data flow interaction and execution between nodes based on interaction terms. This process improves the executability of energy interaction intents and optimizes the collaborative efficiency of the distributed energy system.

[0151] Another embodiment of the present invention provides an energy system data interaction system based on artificial intelligence, see [link to relevant documentation]. Figure 3 The system may include: The receiving module 301 is used to receive encrypted raw operating data and user-preset fuzzy energy consumption preference declaration from the distributed energy user terminal, and extract the real-time physical state feature vector of the local device based on the raw operating data, wherein the fuzzy energy consumption preference declaration includes fuzzy energy consumption target range or priority label. The inference module 302 is used to utilize a lightweight edge AI model deployed on the user terminal side to perform localized energy consumption intention inference based on the real-time physical state feature vector and the fuzzy energy consumption preference declaration, and generate a fine-grained energy consumption intention vector that represents the user's specific, executable but encrypted nature. The energy consumption intention vector includes specific quantitative requirements for grid interaction power, charging and discharging time windows, and adjustable margins. The encapsulation module 303 is used to encapsulate the fine-grained energy consumption intent vector into a structured and standardized intent expression data packet, and broadcast it to nearby energy nodes and regional energy coordinators through a point-to-point network. The matching module 304 is used at the regional energy coordinator to aggregate the received intent expression data packets from multiple nodes, and based on preset consensus rules, perform intent compatibility verification and secure interaction matching to generate an encrypted interaction confirmation instruction set containing the matching node pairs and their interaction terms. The interaction module 305 is used to distribute the encrypted interaction confirmation instruction set to relevant matching nodes, trigger automated, point-to-point energy data flow interaction and execution between nodes based on the interaction terms, and simultaneously synchronize the key summary information of the execution result to the blockchain network for tamper-proof storage.

[0152] This invention also provides a storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above method embodiments when running.

[0153] Specifically, in this embodiment, the storage medium can be configured to store a computer program for performing the following steps: S201, receive encrypted raw operating data and user-preset fuzzy energy consumption preference declaration from distributed energy user terminal, extract real-time physical state feature vector of local device based on the raw operating data, wherein the fuzzy energy consumption preference declaration includes fuzzy energy consumption target range or priority label; S202, using a lightweight edge AI model deployed on the user terminal side, localized energy consumption intention reasoning is performed based on the real-time physical state feature vector and the fuzzy energy consumption preference declaration, generating a fine-grained energy consumption intention vector that represents the user's specific, executable but encrypted nature. The energy consumption intention vector includes specific quantitative requirements for grid interaction power, charging and discharging time windows, and adjustable margins. S203, the fine-grained energy consumption intent vector is encapsulated into a structured, standardized intent expression data packet, and broadcast to neighboring energy nodes and the regional energy coordinator via a point-to-point network; S204, at the regional energy coordinator, the received intent expression data packets from multiple nodes are aggregated, and based on the preset consensus rules, intent compatibility verification and secure interaction matching are performed to generate an encrypted interaction confirmation instruction set containing the matching node pairs and their interaction terms. S205, the encrypted interaction confirmation instruction set is distributed to the relevant matching nodes, triggering automated, point-to-point energy data flow interaction and execution between nodes based on the interaction terms, and simultaneously synchronizing the key summary information of the execution result to the blockchain network for tamper-proof storage.

[0154] This invention also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0155] Specifically, the aforementioned electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the aforementioned processor, and the input / output device is connected to the aforementioned processor.

[0156] Specifically, in this embodiment, the processor can be configured to perform the following steps via a computer program: S201, receive encrypted raw operating data and user-preset fuzzy energy consumption preference declaration from distributed energy user terminal, extract real-time physical state feature vector of local device based on the raw operating data, wherein the fuzzy energy consumption preference declaration includes fuzzy energy consumption target range or priority label; S202, using a lightweight edge AI model deployed on the user terminal side, localized energy consumption intention reasoning is performed based on the real-time physical state feature vector and the fuzzy energy consumption preference declaration, generating a fine-grained energy consumption intention vector that represents the user's specific, executable but encrypted nature. The energy consumption intention vector includes specific quantitative requirements for grid interaction power, charging and discharging time windows, and adjustable margins. S203, the fine-grained energy consumption intent vector is encapsulated into a structured, standardized intent expression data packet, and broadcast to neighboring energy nodes and the regional energy coordinator via a point-to-point network; S204, at the regional energy coordinator, the received intent expression data packets from multiple nodes are aggregated, and based on the preset consensus rules, intent compatibility verification and secure interaction matching are performed to generate an encrypted interaction confirmation instruction set containing the matching node pairs and their interaction terms. S205, the encrypted interaction confirmation instruction set is distributed to the relevant matching nodes, triggering automated, point-to-point energy data flow interaction and execution between nodes based on the interaction terms, and simultaneously synchronizing the key summary information of the execution result to the blockchain network for tamper-proof storage.

[0157] The above description, based on the embodiments shown in the figures, details the structure, features, and effects of the present invention. The above description is only a preferred embodiment of the present invention, but the present invention is not limited to the scope of implementation shown in the figures. Any changes made in accordance with the concept of the present invention, or equivalent embodiments modified to have equivalent changes, that do not exceed the spirit covered by the specification and figures, should be within the protection scope of the present invention.

Claims

1. A data interaction method for energy systems based on artificial intelligence, characterized in that, The method includes: Receive encrypted raw operating data and user-preset fuzzy energy consumption preference declaration from distributed energy user terminal, and extract real-time physical state feature vector of local device based on the raw operating data, wherein the fuzzy energy consumption preference declaration includes fuzzy energy consumption target range or priority label; Using a lightweight edge AI model deployed on the user terminal side, localized energy consumption intention reasoning is performed based on the real-time physical state feature vector and the fuzzy energy consumption preference declaration to generate a fine-grained energy consumption intention vector that represents the user's specific, executable but encrypted needs. The energy consumption intention vector includes specific quantitative requirements for grid interaction power, charging and discharging time windows, and adjustable margins. The fine-grained energy consumption intent vector is encapsulated into a structured, standardized intent expression data packet and broadcast to neighboring energy nodes and the regional energy coordinator via a peer-to-peer network. At the regional energy coordinator, the received intent expression data packets from multiple nodes are aggregated, and based on preset consensus rules, intent compatibility verification and secure interaction matching are performed to generate an encrypted interaction confirmation instruction set containing the matching node pairs and their interaction terms. The encrypted interaction confirmation instruction set is distributed to relevant matching nodes, triggering automated, point-to-point energy data flow interaction and execution between nodes based on the interaction terms. At the same time, the key summary information of the execution result is synchronized to the blockchain network for immutable evidence storage.

2. The method according to claim 1, characterized in that, The process involves receiving encrypted raw operating data and a user-preset fuzzy energy consumption preference statement from a distributed energy user terminal, and extracting a real-time physical state feature vector of the local device based on the raw operating data. The fuzzy energy consumption preference statement includes a fuzzy energy consumption target range or priority label, comprising: The encrypted raw operating data is decrypted in real time, and the plaintext time-series data stream containing voltage fluctuations, current harmonics, and temperature gradients is output. The plaintext time-series data stream is input into the physical feature extraction engine, and the fundamental frequency and transient components are separated by wavelet packet transform, outputting a set of device-level physical state feature fragments; Parse the user's fuzzy energy consumption preference declaration, quantify the target interval as a probability distribution using an interval membership function, and output a priority label vector; By fusing a set of physical state feature fragments with a priority label vector, a real-time physical state feature vector is generated through a feature cross-layer.

3. The method according to claim 2, characterized in that, The process utilizes a lightweight edge AI model deployed on the user terminal side to perform localized energy consumption intent reasoning based on the real-time physical state feature vector and the fuzzy energy consumption preference declaration. This generates a fine-grained energy consumption intent vector that represents the user's specific, executable, but encrypted needs. The energy consumption intent vector includes specific quantitative requirements for grid interaction power, charging / discharging time windows, and adjustable margins, including: Input the real-time physical state feature vector into the temporal convolution module to extract the device operation cycle pattern and output the device state evolution map; A fuzzy rule base is constructed based on priority label vectors, and an adaptive neural inference engine is used to match the optimal rule and output the preliminary intent constraint boundary. Based on the device state evolution graph and intent constraint boundary, fine-grained intent parameters are generated through a reinforcement learning policy network; The executableness of the intent parameters is verified, conflicting schemes are filtered through the physical constraint solver, and a set of valid intent parameters is output. The effective intent parameter set is encoded into an energy consumption intent vector, encrypted using the lightweight national cryptographic algorithm SM4, and the encrypted fine-grained energy consumption intent vector is output.

4. The method according to claim 3, characterized in that, The step of encapsulating the fine-grained energy consumption intent vector into a structured, standardized intent expression data packet and broadcasting it to neighboring energy nodes and the regional energy coordinator via a peer-to-peer network includes: Parse the fine-grained energy consumption intent vector, construct the intent metadata header, and output a structured intent description framework; The intent description framework is bound to a fine-grained energy-consuming intent vector, and intent expression data packets are generated through TLV encoding. Add a lightweight blockchain identity signature to the intent expression data packet to generate a standardized data packet with authentication; Based on a geographic location hash table, nearby energy nodes are selected, and standardized data packets are broadcast to nearby energy nodes and the regional energy coordinator via a low-latency P2P protocol.

5. The method according to claim 4, characterized in that, At the regional energy coordinator, the received intent expression data packets from multiple nodes are aggregated, and based on preset consensus rules, intent compatibility verification and secure interaction matching are performed to generate an encrypted interaction confirmation instruction set containing the matched node pairs and their interaction terms, including: The regional energy coordinator receives intent expression data packets from multiple nodes, verifies identity signatures through zero-knowledge proofs, and outputs a set of trusted nodes and their intent expression data packets. Deconstruct the intent expression data packet to extract power grid interaction power and time window parameters, and construct a multi-dimensional intent compatibility matrix; Input the compatibility matrix into the consensus engine based on Byzantine fault tolerance to verify the supply and demand balance constraints among nodes and output a candidate set of matching node pairs. The matching nodes perform a security assessment on the candidate set, verify the authenticity of the data through privacy-preserving calculations, and generate a risk scoring matrix. Based on the risk scoring matrix and the interaction terms template, an encrypted interaction confirmation instruction set is generated.

6. The method according to claim 5, characterized in that, The process of distributing the encrypted interaction confirmation instruction set to relevant matching nodes triggers automated, peer-to-peer energy data stream interaction and execution between nodes based on the interaction terms, while simultaneously synchronizing the key summary information of the execution result to the blockchain network for immutable notarization, includes: The encrypted interaction confirmation instruction set is pushed to the matching node pair through a secure group key distribution mechanism; After receiving the encrypted interaction confirmation instruction, the matching node automatically decrypts it, triggers the smart contract to parse the interaction terms, and outputs control instructions for the energy data stream. Point-to-point energy interaction is executed based on control commands, and key indicators including power and timestamps are collected in real time to generate execution summary metadata. The execution digest metadata is submitted to the blockchain network, and immutable evidence is stored through a practical Byzantine consensus algorithm.

7. An energy system data interaction system based on artificial intelligence, characterized in that, The system includes: The receiving module is used to receive encrypted raw operating data and user-preset fuzzy energy consumption preference declarations from distributed energy user terminals, and extract real-time physical state feature vectors of local devices based on the raw operating data. The fuzzy energy consumption preference declarations include fuzzy energy consumption target ranges or priority labels. The inference module is used to utilize a lightweight edge AI model deployed on the user terminal side to perform localized energy consumption intention inference based on the real-time physical state feature vector and the fuzzy energy consumption preference declaration, and generate a fine-grained energy consumption intention vector that represents the user's specific, executable but encrypted nature. The energy consumption intention vector includes specific quantitative requirements for grid interaction power, charging and discharging time windows, and adjustable margins. The encapsulation module is used to encapsulate the fine-grained energy consumption intent vector into a structured and standardized intent expression data packet, and broadcast it to neighboring energy nodes and regional energy coordinators through a point-to-point network. The matching module is used at the regional energy coordinator to aggregate the intent expression data packets received from multiple nodes, and based on preset consensus rules, to perform intent compatibility verification and secure interaction matching, and generate an encrypted interaction confirmation instruction set containing the matching node pairs and their interaction terms. The interaction module is used to distribute the encrypted interaction confirmation instruction set to relevant matching nodes, trigger automated, point-to-point energy data flow interaction and execution between nodes based on the interaction terms, and simultaneously synchronize the key summary information of the execution result to the blockchain network for tamper-proof evidence storage.

8. The system according to claim 7, characterized in that, The receiving module is specifically used for: The encrypted raw operating data is decrypted in real time, and the plaintext time-series data stream containing voltage fluctuations, current harmonics, and temperature gradients is output. The plaintext time-series data stream is input into the physical feature extraction engine, and the fundamental frequency and transient components are separated by wavelet packet transform, outputting a set of device-level physical state feature fragments; Parse the user's fuzzy energy consumption preference declaration, quantify the target interval as a probability distribution using an interval membership function, and output a priority label vector; By fusing a set of physical state feature fragments with a priority label vector, a real-time physical state feature vector is generated through a feature cross-layer.

9. A storage medium, characterized in that, The storage medium stores a computer program, wherein the computer program is configured to execute the method of any one of claims 1-6 when it is run.

10. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to run the computer program to perform the method of any one of claims 1-6.

Images