A method and system for integrated energy system planning and operation fusion data stream communication

Abstract

The application discloses a kind of integrated energy system planning operation fusion data stream communication method and system, belong to integrated energy system informatization technical field.It is by constructing five layers of data stream communication architecture, each layer is interacted with service bus through data bus;After standardizing planning boundary condition data, equipment model library is generated by planning state simulation engine to generate planning scheme data and write in digital twin layer to generate model instance;Instance is subscribed by running state optimization engine, generates dispatching instruction in combination with real-time operation data and is issued;After being handled, actual operation data are input into digital twin layer, and deviation factor is calculated by comparing with theoretical model, and when exceeding threshold, model parameters are corrected online and are fed back to planning state simulation engine by reverse data stream, and calibrated planning simulation result is generated.The application solves the problems of planning and operation data stream fusion and model online correction.

Description

Technical Field

[0001] This invention relates to the field of information technology for integrated energy systems, and in particular to a method and system for integrated energy system planning and operation data flow communication. Background Technology

[0002] This invention belongs to the field of information technology for integrated energy systems, specifically relating to a data flow communication method for integrated energy software platforms. It supports the forward connection and reverse feedback between planning-state simulation and operational-state optimization, and is applicable to integrated energy systems that coordinate the management of multiple energy forms such as electricity, heat, cooling, water, gas, and steam.

[0003] Existing integrated energy software platforms typically include two core functions: planning-state simulation and operational-state optimization. However, existing data flow communication designs suffer from the following technical shortcomings:

[0004] First, the data flows between the two states are independent, making model integration difficult. Core data such as equipment models and load curves built in the planning state cannot be automatically transferred to the operational state, requiring remodeling in the operational state and resulting in repetitive work. Although existing patents propose multi-layer architectures or microservice technologies, they do not design a dedicated data flow mechanism for integrating the models of the planning and operational states.

[0005] Second, operational data cannot be fed back in reverse, breaking the optimization closed loop. Actual energy consumption data and equipment status information generated during operation cannot be effectively fed back to the planning stage, failing to form a continuous optimization closed loop of "planning → operation → evaluation → replanning." Existing technologies mostly focus on data quality detection or real-time monitoring during operation, without establishing a reverse transmission channel from operational data to the planning stage.

[0006] Third, cross-level data interaction lacks unified standards, resulting in high integration complexity. Integrated energy systems involve multiple layers, including the physical equipment layer, data foundation layer, digital twin layer, business enablement layer, and application presentation layer, with a lack of standardized data interaction specifications between these layers. While some patents employ unified protocols in specific scenarios, they do not address the fusion communication of planned and operational data, and systematic solutions are lacking for identity verification and trusted transmission issues in multi-energy flow data fusion.

[0007] Therefore, existing technologies lack a systematic solution that can address the interconnection of planning and operational data, model reuse, closed-loop optimization, and cross-level standard interaction from the perspective of data flow communication. Summary of the Invention

[0008] The present invention aims to at least partially solve one of the technical problems in the related art.

[0009] To address this, this invention proposes a fusion data flow communication method for integrated energy system planning and operation. It constructs a five-layer architecture comprising a physical equipment layer, a data foundation layer, a digital twin layer, a business enablement layer, and an application presentation layer. Each layer interacts with a data bus and a service bus. After standardizing the planning boundary condition data, the planning simulation engine calls the equipment model library to generate planning scheme data and writes it into the digital twin layer to generate a model instance. The operation optimization engine subscribes to this instance, integrates real-time operation data to generate scheduling instructions, and issues them for execution. Actual operation data is collected, processed, and input into the digital twin layer. The deviation factor is calculated by comparing it with the theoretical model, and the model parameters are corrected online when a threshold is exceeded. The corrected parameters are fed back to the planning simulation engine to generate calibrated planning simulation results. This invention achieves forward data flow and reverse feedback between the planning and operation states, solving the problems of model reuse and closed-loop optimization.

[0010] Another objective of this invention is to propose a fusion data flow communication system for integrated energy system planning and operation.

[0011] To achieve the above objectives, this invention proposes a method for integrated data flow communication in the planning and operation of a comprehensive energy system, comprising: The planning state boundary condition data is input into the data base layer for standardization processing to obtain standardized input data; the planning state simulation engine of the business enablement layer calls the device model library of the digital twin layer, combines the standardized input data to perform simulation calculations, generates planning scheme data containing device configuration parameters and performance curves, and writes the planning scheme data into the digital twin layer through the data bus to generate a digital twin model instance; The digital twin layer publishes the core information of the digital twin model instance to the message queue through the message bus; the runtime optimization engine of the business enablement layer subscribes to the message queue, reads and caches the digital twin model instance, and combines the real-time physical device layer operation data collected by the data foundation layer to generate optimization scheduling instructions, which are then sent to the physical device layer for execution through the service bus. The actual operating data generated after the physical device layer executes the optimized scheduling instructions is collected through the data base layer. After the actual operating data is cleaned and structured, it is input to the digital twin layer through the data bus. The digital twin layer compares and analyzes the input actual operating data with the theoretical model data in the digital twin model instance item by item, and calculates the deviation factor. When the deviation factor exceeds the preset threshold, the digital twin layer corrects the digital twin model instance online based on the actual operating data and generates the corrected model parameters. The digital twin layer feeds back the corrected model parameters to the planning simulation engine of the business enablement layer through a reverse data stream. The planning simulation engine replaces the original equipment performance curve parameters or load model parameters with the corrected model parameters to generate calibrated planning simulation results.

[0012] The integrated energy system planning and operation fusion data flow communication method of this invention may also have the following additional technical features: In one embodiment of the present invention, the data foundation layer includes a data acquisition unit, a data warehouse unit, and a data governance unit; the step of inputting the planned boundary condition data into the data foundation layer for standardization processing includes: The planned boundary condition data is input into the data acquisition unit, which then accesses the planned boundary condition data through a multi-protocol gateway. The planning boundary condition data is transmitted to the data governance unit, which performs anomaly identification, threshold determination and value compensation on the planning boundary condition data to obtain cleaned planning data. The cleaned planning data is stored in the data warehouse unit, which performs structured transformation on the planning data and outputs standardized input data.

[0013] In one embodiment of the present invention, the digital twin layer includes a modeling configuration unit, a graph model configuration unit, and a monitoring component unit; the step of generating a digital twin model instance includes: The equipment configuration parameters and performance curves in the planning scheme data are input into the modeling configuration unit. The modeling configuration unit performs hierarchical modeling according to plant, bay, and equipment, and defines the static attributes, dynamic telemetry attributes, and remote signaling status attributes of the equipment according to energy type to generate the initial model framework. The initial model framework is input into the graph model configuration unit, which visualizes and constructs the topology of the multi-energy system, generating a structured model containing topological relationships. The structured model is associated and bound with the performance curve to output a complete digital twin model instance, which is then stored in the monitoring component unit for real-time presentation and historical review.

[0014] In one embodiment of the present invention, the data bus is a Kafka-based distributed message queue, and the service bus is a gRPC-based synchronous call framework; the specific steps of the message bus publishing the core information of the digital twin model instance to the message queue are as follows: The digital twin layer constructs and publishes topics according to the Topic naming convention: / data / {data_type} / {plant_id} / {device_id}; where data_type takes the value of model. Encapsulate the device type, key parameters, and performance curve summary of the digital twin model instance into a JSON format message, and set the QoS level to 1 or 2; Messages are published to topics via Kafka producers, while runtime optimization engines subscribe to topics as consumers, receive messages, and cache them in a local distributed cache.

[0015] In one embodiment of the present invention, the method further includes a standardized data interaction specification, which includes a data format standard, an interface protocol standard, and a data quality grading standard; wherein: In accordance with data format standards, equipment model data, real-time telemetry data, and historical statistical data are uniformly encapsulated in JSON format to obtain standard format data; In accordance with the interface protocol standard, when connecting to the energy management system and power grid dispatching platform, the IEC 104 standard data interaction specification is adopted, and the ASDU type identifier 110 is used to transmit planning state model data and the type identifier 111 is used to transmit operation state optimization results; when connecting to the user-side system, RESTful API is used. According to the data quality grading standard, the data is divided into S-level, A-level and B-level, which correspond to the transmission guarantee strategies of synchronous acknowledgment plus a maximum of 3 retransmissions, asynchronous acknowledgment plus 1 retransmission and best-effort no retransmission, respectively, and output a data stream with quality tags.

[0016] In one embodiment of the present invention, the digital twin layer performs a comparative analysis of actual operating data and theoretical model data item by item, including equipment performance comparison, load curve comparison, and cost-benefit comparison; the step of calculating the deviation factor includes: The actual output data of the equipment in the actual operation data and the theoretical efficiency curve in the digital twin model instance are input to the monitoring component unit of the digital twin layer in time segments. The monitoring component unit calculates the efficiency deviation value of each time period and outputs the equipment performance deviation factor. The actual load curve in the actual operation data and the theoretical load prediction model in the digital twin model instance are input to the monitoring component unit of the digital twin layer in time segments. The monitoring component unit calculates the load prediction error for each time period and outputs the load deviation factor. The actual energy cost data from the actual operation data and the theoretical economic analysis results from the digital twin model instance are input into the monitoring component unit of the digital twin layer. The monitoring component unit calculates the cost deviation rate and investment payback period deviation, and outputs the cost-benefit deviation factor.

[0017] In one embodiment of the present invention, the determination step of triggering online correction when the deviation factor exceeds a preset threshold specifically includes: The calculated deviation factor is input into the deviation determination module. The deviation determination module compares the deviation factor with a preset single threshold. If the single deviation exceeds the threshold, the deviation event is recorded and the number of occurrences is accumulated. When the number of consecutive occurrences of deviation events of the same device or load reaches the preset consecutive threshold, it is determined to be a continuous threshold exceeding, and the model correction process is immediately triggered. When the deviation factor exceeds the preset severity threshold, it is determined to be a serious deviation, and the model correction process is immediately triggered, while an alarm notification is sent to the application presentation layer at the same time.

[0018] In one embodiment of the present invention, the step of the digital twin layer performing online correction of the digital twin model instance based on actual operating data includes one or more of the following correction strategies: A parameter calibration strategy is adopted, which inputs the equipment output from the actual operating data and the corresponding operating point into the recursive least squares algorithm, refits the equipment performance curve parameters, and outputs the calibrated efficiency curve coefficients. A model replacement strategy is adopted. When the actual operating data reveals that the deviation between the equipment performance and the current theoretical model exceeds the replacement threshold, a candidate model with a higher matching degree is retrieved from the equipment model library, and the replaced model instance is output. An empirical learning strategy is adopted, in which the load sequence in the actual operation data is used as the training sample and input into the long short-term memory network. The network is updated incrementally with a learning rate of 0.001, and the updated load prediction model parameters are output.

[0019] In one embodiment of the present invention, the method further includes a data stream priority scheduling mechanism, which schedules different types of data streams according to the following steps: The real-time control data stream generated by the runtime optimization engine is marked as the highest priority and input into the preemptible priority queue of the service bus for synchronous processing, ensuring that the maximum latency does not exceed 100ms, and outputting priority scheduling instructions. The real-time monitoring data stream of the physical device layer is marked as high priority, input into the priority queue of the message bus, and transmitted asynchronously to ensure that the delay does not exceed 1 second, and output real-time telemetry data. The model synchronization data stream is marked as medium priority and input into the weighted fair queue of the data bus. It is processed during business idle time to ensure that the delay does not exceed 10 seconds and output the model instance synchronization data. Historical statistics and feedback data streams are marked as low priority and input into the batch processing queue of the data bus. They are aggregated and processed every 15 minutes, and the historical data and correction feedback results are output.

[0020] To achieve the above objectives, another aspect of the present invention proposes a fusion data flow communication system for integrated energy system planning and operation, comprising: The planning and modeling module is used to input the planning boundary condition data into the data base layer for standardization processing to obtain standardized input data. The planning simulation engine of the business enablement layer calls the equipment model library of the digital twin layer, combines the standardized input data to perform simulation calculations, generates planning scheme data containing equipment configuration parameters and performance curves, and writes the planning scheme data into the digital twin layer through the data bus to generate a digital twin model instance. The runtime scheduling module is used by the digital twin layer to publish the core information of the digital twin model instance to the message queue through the message bus; the runtime optimization engine of the business enablement layer subscribes to the message queue, reads and caches the digital twin model instance, and at the same time combines the real-time physical device layer operation data collected by the data foundation layer to generate optimization scheduling instructions, which are then sent to the physical device layer for execution through the service bus. The data acquisition module is used to collect actual operating data generated after the physical device layer executes the optimized scheduling instructions through the data base layer, and after cleaning and structuring the actual operating data, it is input to the digital twin layer through the data bus. The deviation correction module is used by the digital twin layer to compare and analyze the input actual operating data with the theoretical model data in the digital twin model instance item by item, and calculate the deviation factor; when the deviation factor exceeds the preset threshold, the digital twin layer corrects the digital twin model instance online according to the actual operating data and generates the corrected model parameters. The feedback calibration module is used by the digital twin layer to feed back the corrected model parameters to the planning simulation engine of the business enablement layer through a reverse data stream. The planning simulation engine replaces the original equipment performance curve parameters or load model parameters with the corrected model parameters to generate calibrated planning simulation results.

[0021] This invention discloses a method and system for integrated energy system planning and operation data flow communication. By constructing a five-layer architecture comprising a physical device layer, a data foundation layer, a digital twin layer, a business enablement layer, and an application presentation layer, it establishes a positive data connection and reverse data feedback mechanism between planning-state simulation and operational-state optimization. Planning scheme data is automatically generated into digital twin model instances for reuse by the operational-state optimization engine. Based on the deviation factors between actual operational data and the theoretical model, model parameters are corrected online, and the correction results are fed back to the planning-state simulation engine to generate calibrated planning simulation results. This effectively solves the problems in existing technologies where the two-state data are independent, models cannot be reused, and operational data cannot be fed back, leading to broken optimization loops. This invention achieves a continuous optimization loop of planning → operation → evaluation → replanning, significantly improving the model reuse efficiency and collaborative optimization capability of integrated energy systems, enhancing the system's adaptability and engineering practical value under different operating conditions.

[0022] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0023] The above and / or additional aspects and advantages of the present invention will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 This is a flowchart of a method for integrated data flow communication in the planning and operation of a comprehensive energy system according to an embodiment of the present invention; Figure 2 This is a diagram of a five-layer data flow communication architecture according to an embodiment of the present invention; Figure 3 This is a flowchart of the deviation triggering model correction feedback according to an embodiment of the present invention; Figure 4 This is a schematic diagram of the structure of an integrated energy system planning and operation converged data flow communication system according to an embodiment of the present invention. Detailed Implementation

[0024] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other. The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

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

[0026] The following description, with reference to the accompanying drawings, describes a method and system for integrated energy system planning and operation fusion data flow communication according to an embodiment of the present invention.

[0027] The core idea of ​​this invention is to address the problem of independent planning and operational data in integrated energy systems, the inability to reuse models, and the lack of feedback from operational data, which leads to a broken optimization closed loop. This is achieved by constructing a data flow communication method covering the entire process of "planning modeling—digital twin—operation scheduling—deviation correction—feedback calibration." First, a digital twin model instance is generated after standardizing planning boundary conditions based on a five-layer architecture. Then, the operational optimization engine subscribes to and reuses this instance, combining it with real-time operational data to generate scheduling instructions. For deviation factors between actual operational data and the theoretical model, model parameters are corrected online when thresholds are exceeded, and this correction is fed back to the planning simulation engine via reverse data flow to achieve model calibration. Finally, the corrected model parameters are introduced into a new round of planning simulation, establishing a continuous optimization closed loop of planning → operation → evaluation → replanning. Through this technical path that integrates data connectivity, model reuse, and closed-loop feedback, this invention transforms traditional two-state isolated experience-based scheduling into an intelligent communication system capable of adaptive correction and cross-layer collaboration, significantly improving model reuse efficiency and collaborative optimization capabilities between planning and operation.

[0028] The following description, with reference to the accompanying drawings, describes a method and system for integrated data flow communication in the planning and operation of an integrated energy system, according to an embodiment of the present invention.

[0029] like Figure 1 As shown, the integrated energy system planning and operation fusion data flow communication method of the present invention includes the following steps: S1. Input the planning state boundary condition data into the data base layer for standardization processing to obtain standardized input data; the planning state simulation engine of the business enablement layer calls the device model library of the digital twin layer, combines the standardized input data to perform simulation calculations, generates planning scheme data containing device configuration parameters and performance curves, and writes the planning scheme data into the digital twin layer through the data bus to generate a digital twin model instance; S2, the digital twin layer publishes the core information of the digital twin model instance to the message queue through the message bus; the runtime optimization engine of the business enablement layer subscribes to the message queue, reads and caches the digital twin model instance, and at the same time combines the real-time physical device layer operation data collected by the data foundation layer to generate optimization scheduling instructions, which are then sent to the physical device layer for execution through the service bus. S3: Collect actual operating data generated after the physical device layer executes the optimized scheduling command through the data base layer, clean and structure the actual operating data, and then input it to the digital twin layer through the data bus. S4, the digital twin layer compares and analyzes the input actual operating data with the theoretical model data in the digital twin model instance item by item, and calculates the deviation factor; when the deviation factor exceeds the preset threshold, the digital twin layer corrects the digital twin model instance online according to the actual operating data and generates the corrected model parameters; S5, the digital twin layer feeds back the corrected model parameters to the planning simulation engine of the business enablement layer through reverse data flow. The planning simulation engine replaces the original equipment performance curve parameters or load model parameters with the corrected model parameters to generate calibrated planning simulation results.

[0030] In general, the method of this invention is based on a five-layer data flow communication architecture, achieving bidirectional fusion of the planning and running states through two core data flows: a forward-connecting data flow and a reverse-feedback data flow. The system consists of a physical device layer, a data foundation layer, a digital twin layer, a business enablement layer, and an application presentation layer. Data interaction between these layers is achieved through a unified data bus and service bus. The diagram illustrates the five-layer data flow communication architecture of this invention. The layers interact bidirectionally through a data bus (Kafka) and a service bus (gRPC), with the data bus handling asynchronous messages and the service bus handling synchronous calls.

[0031] Specifically, such as Figure 2 As shown, the five-layer data flow communication architecture includes: (1) Physical Equipment Layer: This layer includes various physical devices deployed in the integrated energy system, such as photovoltaic arrays, energy storage systems, refrigeration units, gas boilers, meters, sensors, and controllers. This layer collects data through IoT access gateways, supports multiple industrial protocols such as MQTT, HTTP, Power104, and Modbus, reports raw device data to the upper layer, and receives control commands from the upper layer and sends them to the devices for execution.

[0032] Supported protocols and intervention parameters: MQTT protocol: Topic structure is / energy / {plant_id} / {device_type} / {device_id} / {measurement}, for example / energy / pv_plant_01 / inverter / INV_001 / power, QoS level is set to 1 or 2; Modbus TCP / RTU: Register address mapping table is pre-configured, for example, register address 40001 corresponds to active power (unit kW), and 40002 corresponds to reactive power (unit kvar); IEC 104 protocol: Common address is set to 1, Cause of Transmission is 3 (spontaneous), and information object address is mapped to device measurement point ID; HTTP protocol: POST request is used, data is reported in JSON format, and the interface path is such as / api / v1 / data / upload.

[0033] Data Reporting Format: The gateway converts the collected data into a unified format before reporting it to the data foundation layer. The following is an example of structured data organized in JSON format. Specific details are described below: This data object contains the following three top-level fields: device_id: the value is the string "INV_001", used to uniquely identify the physical device to which the data belongs; timestamp: the value is the string "2025-06-01T10:00:00Z", using ISO 8601 format, recording the time point of data acquisition; measurements: the value is an array type, containing two measurement item elements, each measurement item is a JSON object, defined as follows: The first measurement item contains three fields: name: the value is "active_power", indicating that the name of the measured quantity is active power; value: the value is 150.5, a numeric type, representing the measured value of active power; unit: the value is "kw", indicating that the unit of active power is kilowatt.

[0034] The second measurement item contains three fields: name: the value is "efficiency", indicating that the name of the measured quantity is efficiency; value: the value is 0.96, which is a numeric type and represents the measured value of efficiency; unit: the value is "m³", indicating that the unit of efficiency is cubic meters.

[0035] Receiving control commands: The gateway subscribes to the downlink Topic, such as / control / {device_id} / set, and writes the command to the register according to the corresponding protocol.

[0036] (2) Data Foundation Layer: Responsible for the collection, storage, and management of multi-source heterogeneous data. This layer includes: Data Acquisition Unit: Supports access via multiple protocols such as MQTT, HTTP, Power104, and Modbus, and achieves data acquisition through gateway access, direct device connection, and third-party system interfaces; Data Warehouse Unit: Supports integration with domestic database systems (such as DM and Kingbase), providing data cleaning, structured transformation, and multi-dimensional analysis capabilities; Data Governance Unit: Supports functions such as abnormal data identification, threshold setting, value compensation, data quality rule configuration, and alarm notification.

[0037] This layer provides a unified data foundation for both the planning and operational phases. Historical load data and resource endowment data used in the planning phase and real-time collected data used in the operational phase are managed uniformly within the same data base.

[0038] (3) Digital Twin Layer: Establishing a digital twin model for the integrated energy system is the core hub for the fusion of the two states. An example of the interface definition is as follows: GET / api / v1 / models / {model_id} → Returns model JSON; POST / api / v1 / instances → Creates device instance; GET / api / v1 / instances / {instance_id} / realtime → Returns real-time telemetry data (JSON).

[0039] This layer contains: Modeling configuration unit: Supports hierarchical modeling by plant, bay, and equipment; classifies and creates according to energy types such as electricity, cooling, heating, water, gas, and steam; defines static measurement attributes, dynamic real-time telemetry attributes, remote signaling status attributes, and electricity attributes of equipment; Graphical model configuration unit: Supports visual construction of multi-energy system topology; Monitoring component unit: Provides real-time presentation of equipment attribute status and historical trend backtracking function.

[0040] This layer provides a series of standardized service interfaces, such as real-time data interface, historical data interface, model information interface, instance information interface, and topology search interface, for unified use by planning and running applications.

[0041] (4) Business enablement layer: includes two core components: planning state simulation engine and runtime optimization engine.

[0042] The planning simulation engine calls the digital twin layer model for equipment selection, capacity configuration, economic analysis, and scheme comparison, supporting single-objective / multi-objective optimization; the operation-state optimization engine reuses the same digital twin model and combines real-time data for optimization scheduling and strategy generation, supporting multi-objective integrated energy optimization scheduling with the goal of minimizing cost / carbon emissions, including functions such as prediction center, optimization scheduling center, strategy management, and strategy execution.

[0043] (5) Application presentation layer: Provides user interaction interface, including planning state simulation interface, running state monitoring screen, strategy management interface, report generation tool, etc.

[0044] Furthermore, this invention employs a dual-bus architecture with a message bus and a service bus working together to support efficient data communication between layers. The message bus supports asynchronous publish / subscribe mode for asynchronous communication between modules and real-time data distribution, implemented using a distributed message queue (such as Kafka). The service bus supports synchronous request / response mode, providing functions such as service registration, interface publishing, access control, and call rate limiting. The message bus is responsible for handling the transmission of asynchronous messages such as real-time data and event notifications, while the service bus is responsible for handling synchronous API calls and service orchestration. The two work together: the message bus pushes collected real-time data to modules that need to subscribe through a topic subscription mechanism, while the service bus exposes the interfaces of the planning-state simulation engine and the runtime optimization engine through an API gateway, ensuring reliable communication between layers and modules. Data fusion in a multi-energy flow integrated energy system involves the identity verification and trusted transmission of cross-platform data sources. This invention integrates data source identity authentication and encrypted communication mechanisms into the message bus and service bus, supports blockchain-enabled data source identity verification, and drives data fusion through smart contracts to achieve trusted data flow. Specific interface definitions are as follows: Data bus example: Based on Kafka, Topic naming convention: / data / {data_type} / {plant_id} / {device_id}, where data_type can be realtime, model, or feedback.

[0045] Service Bus Example: Based on gRPC, the service interface definition uses Protocol Buffers, specifically including: defining the gRPC service interface exposed by the digital twin layer using Protocol Buffers syntax. The specific content is described as follows: This service interface is defined as DigitalTwinService, containing two remote procedure call methods: The first method, `rpcGetModel(ModelRequest) returns (ModelResponse)`, is used to request the digital twin model. The input parameter is a `ModelRequest` message type, and the output is a `ModelResponse` message type. The second method, `rpcUpdateInstance(InstanceUpdateRequest) returns (InstanceUpdateResponse)`, is used to request the update of the device instance. The input parameter is an `InstanceUpdateRequest` message type, and the output is an `InstanceUpdateResponse` message type. Additionally, there are two message type field definitions: `ModelRequest` message: contains a field `model_id`, of type string, field number 1, used to specify the requested model identifier; `ModelResponse` message: contains a field `model_json`, of type string, field number 1, used to return the complete model data in JSON format.

[0046] The above interface definitions embody the technical feature of the service bus of this invention supporting synchronous request / response mode. The GetModel method is used by the runtime optimization engine to read model instances from the digital twin layer, and the UpdateInstance method is used by the planning-state simulation engine to write planning scheme data into the digital twin layer to generate or update model instances. The message format follows the standardized data interaction specifications of this invention, and the model_json field uses JSON format to carry model data, ensuring consistency and parsability of cross-layer data exchange.

[0047] Message Format Example: The message format example transmitted via the message bus in this invention is encapsulated using a JSON data structure. The specific content is described as follows: This message object contains the following five top-level fields: msg_id: The value is the string "550e8400-e29b-41d4-a716-446655440000", using a Universally Unique Identifier (UUID) format to uniquely identify this message, supporting message tracking, deduplication, and acknowledgment; timestamp: The value is the numerical value 1717200000, using a Unix timestamp format (second-level precision) to record the message's generation time; source: The value is the string "digital_twin_layer", identifying the message sender as this sender. The digital twin layer is defined as follows: destination: the value is the string "operation_engine", which identifies the expected recipient of the message as the runtime optimization engine of the business enablement layer; payload: the value is a nested JSON object containing three fields: model_id: the value is "model_inst_001", which is a unique identifier for the associated digital twin model instance; type: the value is "pv", which identifies the device type as photovoltaic; params: the value is an object used to carry specific model parameter content, such as structured data such as device performance curve parameters and rated power.

[0048] This message format is used to enable the digital twin layer to publish core information of digital twin model instances to a message queue via a message bus (such as Kafka), which is then subscribed to and consumed by the runtime optimization engine. Specifically, `msg_id` and `timestamp` ensure message traceability, `source` and `destination` define the message route, and the payload carries the actual business data, conforming to the standardized data format requirements for asynchronous message communication in this invention.

[0049] Data source authentication and encryption: TLS 1.3 encrypted transmission and two-way client certificate authentication are used. Blockchain ownership confirmation uses a Hyperledger Fabric consortium blockchain, deployed with 4 organization nodes, and Raft consensus is adopted. A DID (decentralized identity identifier, format did:energy:abc123) is generated upon data source registration, and written to the chain after the smart contract verifies the signature.

[0050] In addition, this invention also establishes a unified data interaction specification to support cross-level data communication. The data interaction specification defines the following: (1) Data format standard: JSON format is uniformly adopted as the carrier for data exchange, and the structured format of various types of data such as device model data, real-time telemetry data, historical statistical data, and interface call parameters is defined; Example of equipment model data: This data object describes a photovoltaic inverter equipment model, containing the following five top-level fields: model_id: The value is the string "pv_inverter_v1", used to uniquely identify this equipment model; type: The value is the string "photovoltaic_inverter", indicating that the equipment type is a photovoltaic inverter; attributes: The value is an array type, containing two attribute definition elements, each attribute being a JSON object, defined as follows: The first attribute object contains three fields: name: The value is "rated_power", indicating that the attribute name is rated power; type: The value is "float", indicating the data type. The first property is a floating-point number; `unit` is "kW", indicating the unit is kilowatts; `default` is 100.0, indicating the default value; the second property object contains three fields: `name` is "efficiency_curve", indicating the property name is efficiency curve; `type` is "array", indicating the data type is array; `description` is "efficiency curve parameter", used to describe the meaning of the property; `static_properties`: is a nested JSON object containing two fields: `manufacturer` is "Huawei", indicating the manufacturer; `model` is "SUN2000", indicating the product model. This field is used to describe the static invariant properties of the device; `dynamic_properties`: is an array type containing three string elements: "active_power", "reactive_power", and "temperature", used to list the names of the device's dynamic telemetry properties. This data structure reflects the standardized definition of device model data in this invention, where the `attributes` field is used to declare configurable parameters and their default values, `static_properties` is used to record the inherent properties of the device, and `dynamic_properties` is used to specify the dynamic measurements that need to be collected in real time. This format can be used by planned-state simulation engines as model templates, and can also be used by digital twin layers to generate specific device instances. Example of real-time telemetry data: This data object contains the following three top-level fields: `instance_id`: The value is the string "inv_01", used to uniquely identify the digital twin model instance that generated this data, corresponding to the specific device instance in the physical device layer; `timestamp`: The value is the numerical value 1717200000, using Unix timestamp format (second-level precision), recording the time point of telemetry data acquisition; `data`: The value is a nested JSON object containing two key-value pairs: `active_power` is 85.3, representing the active power measurement value in kW (based on the device model definition); `efficiency` is 0.97, representing the efficiency measurement value, a dimensionless value. This field is used to carry the real-time sampled values ​​of one or more dynamic telemetry attributes of the device. This data structure is used by the runtime optimization engine to obtain the real-time telemetry data format after real-time acquisition of physical device layer operation data through the data foundation layer, and is also used for the real-time presentation of device attribute status by the digital twin layer monitoring component unit. This format conforms to the definition of real-time telemetry data in the standardized data interaction specification of this invention.

[0051] (2) Interface Protocol Standards: When connecting to the Energy Management System (EMS) and power grid dispatching platform, the IEC 104 standard data interaction specification is adopted, and a custom ASDU type is defined: type identifier 110 is used to transmit planning state model data, and type identifier 111 is used to transmit operational state optimization results. When connecting to the user-side system, a RESTful API is used, such as GET / api / v1 / energy and POST / api / v1 / control. An integrated IEC 104 standard data interaction specification is developed to achieve cross-level data synchronization.

[0052] (3) Data quality grading standard: Data is divided into S level (core data, ensure integrity, synchronous confirmation + up to 3 retransmissions), A level (important data, ensure accuracy, asynchronous confirmation + 1 retransmission), and B level (general data, ensure availability, try to avoid retransmission). Different transmission guarantee strategies are adopted for different levels.

[0053] In addition, this invention introduces a data source identity verification and trusted transmission mechanism in the multi-energy stream data fusion process. Specifically, it includes: (1) Data source identity verification: verifying the identity of data sources on each platform, and ensuring the authenticity and immutability of data sources through blockchain or digital certificate technology; (2) Smart contract-driven data fusion: automatically executing data fusion rules based on smart contracts, triggering the fusion process when data from multiple data sources meets preset conditions, without the need for manual intervention; (3) Trusted transmission channel: cross-platform data interaction is carried out through an encrypted channel to ensure the security and integrity of data transmission.

[0054] The method of this invention effectively solves the problems in the prior art where two-state data are independent, models cannot be reused, and operational data cannot be fed back in reverse, leading to the breakage of the optimization closed loop. It realizes a continuous optimization closed loop of planning → operation → evaluation → replanning, significantly improves the model reuse efficiency and planning-operation collaborative optimization capability of the integrated energy system, and enhances the system's adaptability and engineering practical value under different operating conditions.

[0055] Furthermore, taking a comprehensive energy project in an industrial park as an example: Park overview: 500kW photovoltaic power, 200kWh energy storage, 300kW air conditioning, peak electricity load 800kW. Planning inputs: historical load data (hourly in 2024), irradiance, peak electricity price 1.2 yuan / kWh, valley price 0.3 yuan / kWh; real-time operation data: photovoltaic power, energy storage SOC, air conditioning status, real-time electricity price.

[0056] 1. Forward data flow (planning state → running state).

[0057] Step 1: Data collection and standardization in the planning state.

[0058] Planning engineers input boundary conditions, including load forecast data, resource endowment data, electricity pricing policies, and carbon emission constraints, through the planning simulation interface in the application presentation layer. The data foundation layer standardizes these input data, converting them into standardized data in a unified format, and stores them in the data warehouse unit. The data governance unit performs quality checks on the input data, identifying and marking abnormal data.

[0059] For example, input an annual total load growth rate of 3% and a carbon price of 50 yuan / ton. The data is stored after standardization at the data base layer. Input data example: This data object contains the following two top-level fields: `load_data`: The value is an array type, with array elements being numeric types. The example gives values ​​such as 1200.5 and 1250.3 (more data points are indicated by "..."), used to represent the time series of load forecast data, in kW (based on typical power system units). This sequence is arranged in chronological order, with each value corresponding to a load forecast value for a sampling period. `tariff`: The value is a nested JSON object containing three key-value pairs: `peak`: 1.2, representing the peak electricity price in yuan / kWh; `valley`: 0.3, representing the valley electricity price in yuan / kWh; `shoulder`: 0.7, representing the normal electricity price in yuan / kWh. This data structure is used by planning engineers to input boundary condition data through the planning simulation interface of the application presentation layer. The `load_data` field carries historical or predicted load data, and the `tariff` field carries time-of-use electricity price policy parameters. After being standardized by the data base layer, this data is used by the planning-state simulation engine for simulation calculations such as equipment selection, capacity configuration, and economic analysis. This format conforms to the definition of planning-state input data in the standardized data interaction specification of this invention. Step 2: Planned state simulation and model generation.

[0060] The planning-state simulation engine requests model templates from the device model library in the digital twin layer via the service bus to obtain the static attributes and default performance curves of each device. Simultaneously, the planning-state simulation engine calls upon historical data (such as historical electricity load of the park and local meteorological data) in the data foundation layer for simulation calculations. The planning-state simulation engine runs a multi-objective optimization algorithm and outputs a planning scheme, including a device selection list, capacity configuration parameters, recommended device models, device performance curve parameters, and economic analysis results.

[0061] For example, a recommended solution is given using the multi-objective optimization algorithm (NSGA-II): 550kW photovoltaic power and 250kWh energy storage.

[0062] Step 3: Write the planning results into the digital twin layer.

[0063] Once the planning scheme is confirmed, the planning-state simulation engine writes the aforementioned configuration parameters into the digital twin layer in a standardized data format via the data bus. Based on these parameters, the digital twin layer generates a digital twin model instance for the project. This instance includes complete static attributes of the equipment (model, rated power, rated efficiency), dynamic attributes (current value placeholders), and performance curves (power generation efficiency curve, charge / discharge efficiency curve, energy efficiency ratio curve, etc.). During the writing process, the data governance unit verifies the written data to ensure its integrity and consistency.

[0064] For example, key parameters of the model instance after writing: {"pv_efficiency_curve":[[200,0.95],[400,0.96],[600,0.94]]}.

[0065] Step 4: Synchronize the planning model to the message bus.

[0066] After the digital twin layer generates a model instance, it publishes the core information of the model instance (device type, key parameters, and performance curve summary) to a specific topic in the message queue via a message bus. The runtime optimization engine subscribes to this topic, receives model synchronization notifications in real time, and caches the model information locally or in a distributed cache.

[0067] For example, the model instance ID model_inst_001 is published to Topic / data / model / plant_01.

[0068] Step 5: The runtime engine reads the model.

[0069] Once the project is officially launched, when the runtime optimization engine starts, it queries the digital twin layer for the corresponding digital twin model instance through the service bus, directly reading parameters such as equipment model, performance curves, pricing models, and load models. The runtime optimization engine obtains high-precision prediction data through standardized data interfaces for optimizing scheduling calculations, eliminating the need for manual re-entry.

[0070] For example, you can call GET / api / v1 / instances / model_inst_001 to get all the parameters.

[0071] Step 6: Runtime optimization and instruction issuance.

[0072] Based on the above model, the runtime optimization engine combines real-time data (real-time device power, energy storage SOC, ambient temperature, etc.) provided by the data foundation layer to perform optimization scheduling calculations. The optimization engine generates scheduling strategies with the goal of minimizing cost / carbon emissions, and then sends control commands to the physical device layer for execution via the service bus through the strategy execution module.

[0073] For example, real-time data: 450kW photovoltaic power, 60% SOC of energy storage, peak electricity price period. Strategy: Discharge energy storage to 25%, limit air conditioning power to 80kW. Send instructions to the PLC.

[0074] 2. Reverse feedback data flow (running state → planning state).

[0075] Step 1: Acquisition of runtime data.

[0076] The operational optimization engine runs continuously, collecting actual operational data from the physical device layer through the IoT access unit in the data foundation layer. This includes: actual equipment output data (actual photovoltaic power generation, actual energy storage charging and discharging power, actual air conditioning cooling capacity, etc.); equipment operating status data (online / offline, fault / normal, start / stop status, etc.); scheduling command execution effect data (command execution time, execution deviation, execution success rate, etc.); and energy cost and carbon emission data (actual electricity cost, gas cost, carbon emission, etc.).

[0077] For example, after 30 days of operation, the actual photovoltaic efficiency curve is collected: [(200,0.94),(400,0.92),(600,0.91)].

[0078] The theoretical value should be [(200,0.95),(400,0.96),(600,0.94)].

[0079] Average efficiency deviation -2.8%, maximum -4.2%.

[0080] Step 2: Data storage and quality governance.

[0081] The data foundation layer cleanses and structures the collected operational data before writing it to the data warehouse unit via the data bus. The data governance unit assesses the quality of the operational data, identifies anomalous data, and performs value imputation or marking to ensure the quality of data entering subsequent analysis stages. Simultaneously, the data governance unit issues alerts for operational data that continuously deviates from the normal range based on preset data quality rules.

[0082] For example, outliers (power drops to 0) are compensated by linear interpolation.

[0083] Step 3: Comparative analysis of running data and planning model.

[0084] The digital twin layer periodically (e.g., daily, weekly, or triggered) reads operational data from the data warehouse unit and compares the actual operational data with the theoretical model data used in the planning phase, item by item: Equipment performance comparison: The actual power generation efficiency / operating efficiency of the equipment is compared with the theoretical efficiency curve for each time period to calculate the deviation factor and deviation trend; Load curve comparison: The actual load curve is compared with the planned load forecast model for each time period to calculate the forecast error distribution; Cost-benefit comparison: The actual energy cost is compared with the planned economic analysis results to calculate the cost deviation and investment payback period deviation.

[0085] For example, at a 500kW point, the theoretical efficiency is 0.96, the actual efficiency is 0.92, and the deviation is -4.2%. The average daily error of load forecasting is 8.3%.

[0086] Step 4: Deviation Trigger and Model Correction Determination.

[0087] When the deviation generated by the comparative analysis exceeds a preset threshold (e.g., equipment efficiency deviation exceeds 5%, load prediction error exceeds 10%, cost deviation exceeds 8%), the digital twin layer automatically triggers the model correction process. The judgment logic is as follows: Single deviation exceeding the threshold: record the deviation event and accumulate statistics; continuous deviation exceeding the threshold: immediately trigger model correction; deviation magnitude exceeding the severe threshold (e.g., efficiency deviation exceeds 15%): immediately trigger model correction and send an alarm.

[0088] For example, threshold settings: efficiency deviation of 5% triggered 3 times consecutively; load error of 10% triggered once; cost deviation of 8%. In this example, the deviation is 4.2% < 5%, so no correction is triggered. If the efficiency deviation reaches 5.5% on a certain day and continues for 3 days, then a correction will be triggered.

[0089] Step 5: Online correction of the digital twin model. For example... Figure 3 As shown.

[0090] Based on the deviation data, the digital twin layer adjusts the model parameters using one or more of the following correction strategies: Parameter calibration: Refit the equipment performance curve parameters based on actual operating data and adjust the coefficients in the efficiency model; Model replacement: If actual operating data reveals that the equipment performance deviates too much from the theoretical model, select a more suitable model from the model library to replace the original model; Experience learning: Use actual operating data as training samples to incrementally update the parameters of the load prediction model, making subsequent predictions more realistic; Knowledge graph update: Write the corrected model parameters and equipment characteristic data into the knowledge graph for intelligent recommendation of subsequent planning scenarios.

[0091] Once the correction is triggered, the efficiency curve is refitted using recursive least squares (RLS):

[0092]

[0093]

[0094] in For polynomial coefficients, For power input, =0.95.

[0095] Load forecast incremental update: using LSTM, SGD optimization, learning rate 0.001, loss function MSE.

[0096] Step 6: Feedback the correction results to the planning state.

[0097] The corrected digital twin model is stored as empirical data and simultaneously fed back to the planning simulation engine via a reverse data stream: the corrected equipment performance curves are stored in the equipment model toolbox for use in the planning simulation of other projects; the corrected load model parameters are fed back to the load model toolbox to optimize the load forecasting algorithm; and the corrected economic analysis parameters (such as the payback period correction coefficient) are stored in the planning economic analysis model library.

[0098] For example, the efficiency curve parameters are saved after correction, and the version number changes from v1 to v2.

[0099] Step 7: Re-evaluate the planning scheme.

[0100] Planning engineers can view model revision records and deviation analysis reports in the application presentation layer. For completed projects, they can choose whether to apply the revised model parameters to the re-evaluation of existing planning schemes, generate revised planning reports, and verify the differences between the planning scheme and the actual operating results, as well as the room for improvement.

[0101] For example, a re-simulation revealed that the investment payback period was revised from 5.2 years to 5.5 years, leading to adjustments in equipment selection.

[0102] 3. A complete data flow closed loop for the fusion of two states.

[0103] Planning-state simulation → Data standardization → Model writing to digital twin layer → Model synchronization to message bus → Running-state model reading → Real-time optimization and scheduling → Running data acquisition → Data storage and management → Comparison of running data and model → Deviation determination → Online model correction → Correction data feedback to planning state → Improve the accuracy of subsequent planning.

[0104] 3. Data flow priority and scheduling mechanism.

[0105] In scenarios where multiple data streams coexist, this invention sets up a data stream priority scheduling mechanism based on the timeliness and importance requirements of different data: Real-time control data stream (highest priority): Scheduling instructions generated by the runtime optimization engine, requiring millisecond-level delivery, are prioritized for synchronous processing via the service bus; maximum latency ≤100ms, using a preemptible priority queue; Real-time monitoring data stream (high priority): Real-time telemetry data from devices, requiring second-level transmission, is transmitted asynchronously via the message bus, with latency ≤1s, using a FIFO + priority queue; Model synchronization data stream (medium priority): Data written to the planning-state model and read from the runtime model, requiring completion within seconds to minutes, is prioritized for processing during idle business hours via the data bus, with latency ≤10s, using a weighted fair queue (WFQ); Historical statistics and feedback data stream (low priority): Historical data entering the database and reverse feedback data during runtime, accepting latency of minutes to hours, is processed in batches via the data bus when system load is low, with latency ≤1h, batch processing (aggregation every 15 minutes).

[0106] The application of the method in this invention effectively solves the problems in the prior art where two-state data are independent, models cannot be reused, and operational data cannot be fed back, leading to a broken optimization closed loop. It achieves a continuous optimization closed loop of planning → operation → evaluation → replanning, significantly improving model reuse efficiency and collaborative optimization capabilities, and enhancing the system's adaptability and engineering practical value under different operating conditions.

[0107] To achieve the above invention, such as Figure 4 As shown, this embodiment also provides a fusion data flow communication system 10 for integrated energy system planning and operation. The system 10 includes: The planning modeling module 100 is used to input the planning state boundary condition data into the data base layer for standardization processing to obtain standardized input data. The planning state simulation engine of the business enablement layer calls the equipment model library of the digital twin layer, combines the standardized input data to perform simulation calculations, generates planning scheme data containing equipment configuration parameters and performance curves, and writes the planning scheme data into the digital twin layer through the data bus to generate a digital twin model instance.

[0108] The runtime scheduling module 200 is used by the digital twin layer to publish the core information of the digital twin model instance to the message queue through the message bus; the runtime optimization engine of the business enablement layer subscribes to the message queue, reads and caches the digital twin model instance, and at the same time combines the real-time physical device layer operation data collected by the data base layer to generate optimization scheduling instructions, which are then sent to the physical device layer for execution through the service bus.

[0109] The data acquisition module 300 is used to acquire the actual operating data generated after the physical device layer executes the optimized scheduling instructions through the data base layer, clean and structure the actual operating data, and then input it to the digital twin layer through the data bus.

[0110] The deviation correction module 400 is used by the digital twin layer to compare and analyze the input actual operating data with the theoretical model data in the digital twin model instance item by item, and calculate the deviation factor; when the deviation factor exceeds the preset threshold, the digital twin layer corrects the digital twin model instance online according to the actual operating data and generates the corrected model parameters.

[0111] The feedback calibration module 500 is used by the digital twin layer to feed back the corrected model parameters to the planning simulation engine of the business enablement layer through a reverse data stream. The planning simulation engine replaces the original equipment performance curve parameters or load model parameters with the corrected model parameters to generate calibrated planning simulation results.

[0112] The system of this invention effectively solves the problems in the prior art where two-state data are independent, the model cannot be reused, and the running data cannot be fed back in reverse, resulting in the break of the optimization closed loop. It realizes a continuous closed loop of planning → running → evaluation → replanning, and significantly improves the model reuse efficiency and collaborative optimization capability.

[0113] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0114] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this invention, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.

Claims

1. A method for integrated data flow communication in the planning and operation of a comprehensive energy system, characterized in that, The method is implemented based on a five-layer data flow communication architecture, which includes a physical device layer, a data foundation layer, a digital twin layer, a business enablement layer, and an application presentation layer. These layers interact with each other via a data bus and a service bus. The method includes the following steps: The planning state boundary condition data is input into the data base layer for standardization processing to obtain standardized input data; the planning state simulation engine of the business enablement layer calls the device model library of the digital twin layer, combines the standardized input data to perform simulation calculations, generates planning scheme data containing device configuration parameters and performance curves, and writes the planning scheme data into the digital twin layer through the data bus to generate a digital twin model instance; The digital twin layer publishes the core information of the digital twin model instance to the message queue through the message bus; the runtime optimization engine of the business enablement layer subscribes to the message queue, reads and caches the digital twin model instance, and combines the real-time physical device layer operation data collected by the data foundation layer to generate optimization scheduling instructions, which are then sent to the physical device layer for execution through the service bus. The actual operating data generated after the physical device layer executes the optimized scheduling instructions is collected through the data base layer. After the actual operating data is cleaned and structured, it is input to the digital twin layer through the data bus. The digital twin layer compares and analyzes the input actual operating data with the theoretical model data in the digital twin model instance item by item, and calculates the deviation factor. When the deviation factor exceeds the preset threshold, the digital twin layer corrects the digital twin model instance online based on the actual operating data and generates the corrected model parameters. The digital twin layer feeds back the corrected model parameters to the planning simulation engine of the business enablement layer through a reverse data stream. The planning simulation engine replaces the original equipment performance curve parameters or load model parameters with the corrected model parameters to generate calibrated planning simulation results.

2. The method as described in claim 1, characterized in that, The data infrastructure layer includes a data acquisition unit, a data warehouse unit, and a data governance unit; The steps for inputting the planned boundary condition data into the data base layer for standardization include: The planned boundary condition data is input into the data acquisition unit, which then accesses the planned boundary condition data through a multi-protocol gateway. The planning boundary condition data is transmitted to the data governance unit, which performs anomaly identification, threshold determination and value compensation on the planning boundary condition data to obtain cleaned planning data. The cleaned planning data is stored in the data warehouse unit, which performs structured transformation on the planning data and outputs standardized input data.

3. The method as described in claim 1, characterized in that, The digital twin layer includes modeling configuration units, graphical model configuration units, and monitoring component units; The steps to generate a digital twin model instance include: The equipment configuration parameters and performance curves in the planning scheme data are input into the modeling configuration unit. The modeling configuration unit performs hierarchical modeling according to plant, bay, and equipment, and defines the static attributes, dynamic telemetry attributes, and remote signaling status attributes of the equipment according to energy type to generate the initial model framework. The initial model framework is input into the graph model configuration unit, which visualizes and constructs the topology of the multi-energy system, generating a structured model containing topological relationships. The structured model is associated and bound with the performance curve to output a complete digital twin model instance, which is then stored in the monitoring component unit for real-time presentation and historical review.

4. The method as described in claim 1, characterized in that, The data bus is a Kafka-based distributed message queue, and the service bus is a gRPC-based synchronous call framework. The specific steps for the message bus to publish the core information of the digital twin model instance to the message queue are as follows: The digital twin layer constructs and publishes topics according to the Topic naming convention: / data / {data_type} / {plant_id} / {device_id}; where data_type takes the value of model. Encapsulate the device type, key parameters, and performance curve summary of the digital twin model instance into a JSON format message, and set the QoS level to 1 or 2; Messages are published to topics via Kafka producers, while runtime optimization engines subscribe to topics as consumers, receive messages, and cache them in a local distributed cache.

5. The method as described in claim 1, characterized in that, The method also includes standardized data interaction specifications, which include data format standards, interface protocol standards, and data quality grading standards; wherein: In accordance with data format standards, equipment model data, real-time telemetry data, and historical statistical data are uniformly encapsulated in JSON format to obtain standard format data; In accordance with the interface protocol standard, when connecting to the energy management system and power grid dispatching platform, the IEC 104 standard data interaction specification is adopted, and the ASDU type identifier 110 is used to transmit planning state model data and the type identifier 111 is used to transmit operation state optimization results; when connecting to the user-side system, RESTful API is used. According to the data quality grading standard, the data is divided into S-level, A-level and B-level, which correspond to the transmission guarantee strategies of synchronous acknowledgment plus a maximum of 3 retransmissions, asynchronous acknowledgment plus 1 retransmission and best-effort no retransmission, respectively, and output a data stream with quality tags.

6. The method as described in claim 1, characterized in that, The digital twin layer compares and analyzes actual operating data with theoretical model data item by item, including equipment performance comparison, load curve comparison, and cost-benefit comparison. The steps for calculating the deviation factor include: The actual output data of the equipment in the actual operation data and the theoretical efficiency curve in the digital twin model instance are input to the monitoring component unit of the digital twin layer in time segments. The monitoring component unit calculates the efficiency deviation value of each time period and outputs the equipment performance deviation factor. The actual load curve in the actual operation data and the theoretical load prediction model in the digital twin model instance are input to the monitoring component unit of the digital twin layer in time segments. The monitoring component unit calculates the load prediction error for each time period and outputs the load deviation factor. The actual energy cost data from the actual operation data and the theoretical economic analysis results from the digital twin model instance are input into the monitoring component unit of the digital twin layer. The monitoring component unit calculates the cost deviation rate and investment payback period deviation, and outputs the cost-benefit deviation factor.

7. The method according to claim 1, characterized in that, The specific steps for determining when the deviation factor exceeds a preset threshold and triggers online correction are as follows: The calculated deviation factor is input into the deviation determination module. The deviation determination module compares the deviation factor with a preset single threshold. If the single deviation exceeds the threshold, the deviation event is recorded and the number of occurrences is accumulated. When the number of consecutive occurrences of deviation events of the same device or load reaches the preset consecutive threshold, it is determined to be a continuous threshold exceeding, and the model correction process is immediately triggered. When the deviation factor exceeds the preset severity threshold, it is determined to be a serious deviation, and the model correction process is immediately triggered, while an alarm notification is sent to the application presentation layer at the same time.

8. The method according to claim 1, characterized in that, The steps for the digital twin layer to perform online corrections on digital twin model instances based on actual operational data include one or more of the following correction strategies: A parameter calibration strategy is adopted, which inputs the equipment output from the actual operating data and the corresponding operating point into the recursive least squares algorithm, refits the equipment performance curve parameters, and outputs the calibrated efficiency curve coefficients. A model replacement strategy is adopted. When the actual operating data reveals that the deviation between the equipment performance and the current theoretical model exceeds the replacement threshold, a candidate model with a higher matching degree is retrieved from the equipment model library, and the replaced model instance is output. An empirical learning strategy is adopted, in which the load sequence in the actual operation data is used as the training sample and input into the long short-term memory network. The network is updated incrementally with a learning rate of 0.001, and the updated load prediction model parameters are output.

9. The method according to claim 1, characterized in that, The method also includes a data stream priority scheduling mechanism, which schedules different types of data streams according to the following steps: The real-time control data stream generated by the runtime optimization engine is marked as the highest priority and input into the preemptible priority queue of the service bus for synchronous processing, ensuring that the maximum latency does not exceed 100ms, and outputting priority scheduling instructions. The real-time monitoring data stream of the physical device layer is marked as high priority, input into the priority queue of the message bus, and transmitted asynchronously to ensure that the delay does not exceed 1 second, and output real-time telemetry data. The model synchronization data stream is marked as medium priority and input into the weighted fair queue of the data bus. It is processed during business idle time to ensure that the delay does not exceed 10 seconds and output the model instance synchronization data. Historical statistics and feedback data streams are marked as low priority and input into the batch processing queue of the data bus. They are aggregated and processed every 15 minutes, and the historical data and correction feedback results are output.

10. A fusion data flow communication system for integrated energy system planning and operation, characterized in that, The system is built on a five-layer data flow communication architecture, including: The planning and modeling module is used to input the planning boundary condition data into the data base layer for standardization processing to obtain standardized input data. The planning simulation engine of the business enablement layer calls the equipment model library of the digital twin layer, combines the standardized input data to perform simulation calculations, generates planning scheme data containing equipment configuration parameters and performance curves, and writes the planning scheme data into the digital twin layer through the data bus to generate a digital twin model instance. The runtime scheduling module is used by the digital twin layer to publish the core information of the digital twin model instance to the message queue through the message bus; the runtime optimization engine of the business enablement layer subscribes to the message queue, reads and caches the digital twin model instance, and at the same time combines the real-time physical device layer operation data collected by the data foundation layer to generate optimization scheduling instructions, which are then sent to the physical device layer for execution through the service bus. The data acquisition module is used to collect actual operating data generated after the physical device layer executes the optimized scheduling instructions through the data base layer, and after cleaning and structuring the actual operating data, it is input to the digital twin layer through the data bus. The deviation correction module is used by the digital twin layer to compare and analyze the input actual operating data with the theoretical model data in the digital twin model instance item by item, and calculate the deviation factor; when the deviation factor exceeds the preset threshold, the digital twin layer corrects the digital twin model instance online according to the actual operating data and generates the corrected model parameters. The feedback calibration module is used by the digital twin layer to feed back the corrected model parameters to the planning simulation engine of the business enablement layer through a reverse data stream. The planning simulation engine replaces the original equipment performance curve parameters or load model parameters with the corrected model parameters to generate calibrated planning simulation results.

Images