Interface implementation method and device for photovoltaic grid-connected power distribution network multi-source data fusion

Abstract

This application provides an interface implementation method and apparatus for multi-source data fusion in photovoltaic grid-connected distribution networks, relating to the field of power system automation technology. The method includes: acquiring raw data packets uploaded by devices at each end; identifying the corresponding communication protocol based on device identifiers, loading the corresponding protocol adapter from a pre-set protocol adapter library, converting the raw data packets into data with a unified data format according to the data address mapping table corresponding to the device, and performing multi-layer quality checks, automatically repairing data that fails the checks; using a three-layer caching architecture to classify and store the data after quality checks and repairs according to real-time requirements; responding to client data access requests, verifying client access permissions, extracting data according to the push protocol supported by the client, and pushing it to the client, thereby improving the shortcomings of existing interface solutions in terms of data access universality, quality reliability, real-time transmission, and operational security.

Description

Technical Field

[0001] This application relates to the field of power system automation technology, and in particular to an interface implementation method and apparatus for multi-source data fusion in photovoltaic grid-connected distribution networks. Background Technology

[0002] In recent years, the installed capacity of new energy power generation, represented by photovoltaic (PV) power generation, has continued to grow rapidly. A large number of distributed PV power sources are connected to the grid in a decentralized, multi-point access manner, gradually transforming the traditional distribution network into an active distribution network containing multiple types of distributed power sources, diverse loads, and energy storage devices. Against this backdrop, the operating characteristics of PV grid-connected distribution networks have undergone profound changes. Their fault characteristics differ significantly from those of traditional synchronous generator power supply systems, posing new technical challenges to fault detection, location, and isolation in distribution networks. Achieving comprehensive, real-time, and accurate collection and fusion of massive amounts of data from distributed PV devices, grid-connected nodes, and environmental monitoring is a fundamental prerequisite for building an intelligent PV distribution network fault handling system. However, due to the diverse types of equipment involved in PV grid connection, varying communication protocols, massive data volumes, and high real-time requirements, how to overcome the challenges of efficient fusion interface technology for multi-source heterogeneous data has become a key technical problem urgently needing to be solved in this field.

[0003] Currently, existing interface solutions for photovoltaic grid-connected distribution networks are mainly implemented as follows: For various connected photovoltaic inverters, smart meters, and grid-connected switches, the interface program develops corresponding protocol parsing drivers based on the communication protocol types supported by each device (such as IEC 61850, DNP3.0, Modbus TCP, DL / T 645, etc.) and the register address mapping table provided by the manufacturer. Data read commands are sent to each device through polling, the returned raw messages are received and parsed, and operating parameters such as voltage, current, and power are extracted. The parsed data is then written into a real-time database for use by the upper-level monitoring and fault handling systems. However, the above interface solutions have shortcomings in terms of data access universality, quality reliability, real-time transmission, and operational security, making it difficult to meet the needs of efficient integration and access of multi-source heterogeneous data in photovoltaic grid-connected distribution networks. Summary of the Invention

[0004] This application provides an interface implementation method and apparatus for multi-source data fusion in photovoltaic grid-connected distribution networks, which improves the shortcomings of related technologies in terms of data access universality, quality reliability, transmission real-time performance and operational security, making it difficult to meet the needs of efficient fusion access of multi-source heterogeneous data in photovoltaic grid-connected distribution networks.

[0005] Firstly, this application provides an interface implementation method for multi-source data fusion in photovoltaic grid-connected distribution networks, including:

[0006] Obtain the raw data packets uploaded by devices at each end of the photovoltaic grid-connected distribution network;

[0007] Based on the device identifier, the communication protocol corresponding to the original data packet is identified. According to the identification result, the corresponding protocol adapter is loaded from the preset protocol adapter library. The original data packet is converted into data with a unified data format through the protocol adapter according to the data address mapping table corresponding to the device.

[0008] Perform multi-layer quality checks on data with a uniform data format, and generate quality labels and perform automatic repairs on data that fails the checks.

[0009] A three-tier caching architecture is used to classify and store data that has undergone quality verification and repair according to real-time requirements.

[0010] In response to a client's data access request, the system verifies the client's access permissions according to a preset role-based access control policy. Once the verification is successful, the system retrieves data from the three-tier caching architecture as needed and pushes it to the client according to the push protocol supported by the client.

[0011] In one possible embodiment, the original data packet is converted into data with a unified data format according to the data address mapping table corresponding to the device, including: parsing the original data packet to extract the register address and register value; mapping the register address to an internal unified data object identifier according to the data address mapping table; converting the register value to a value in engineering units according to a preset unit conversion factor in the data address mapping table; and encapsulating the data object identifier and the value in engineering units into data with a unified data format according to a preset unified data structure.

[0012] In one possible embodiment, multi-layer quality checks are performed on data with a unified data format, including: performing a range check on the data with a unified data format to verify whether the data value of the data with a unified data format is within a preset physical range; performing a rate of change check on the data with a unified data format to verify whether the rate of change between the data value at the current sampling time and the data value at the previous sampling time exceeds a preset maximum allowable rate of change threshold; performing a consistency check on the data with a unified data format to verify whether the logical relationship between the data value of the data with a unified data format and the data value of the associated data point meets preset logical constraints; performing an integrity check on the data with a unified data format to verify whether the data frame structure corresponding to the data with a unified data format is complete and whether any required fields are missing; and generating corresponding quality labels based on the results of each check.

[0013] In one possible embodiment, for data that fails quality verification, automatic repair is performed according to a preset repair strategy, including: for data that fails the check because the data value exceeds a preset physical range or because the rate of change exceeds a preset maximum allowable rate of change threshold, generating repair data using interpolation; for data that fails the check because a required field is missing or the data frame structure is incomplete, generating predicted data using a preset time series prediction model to fill in the missing values; for data that fails the check because the logical relationship does not meet the logical constraints, calculating the theoretical value of the related data point as the dependent variable from the related data point as the independent variable based on the physical constraint relationship between the related data points involved in the logical constraints, and replacing the corresponding measured value with the theoretical value for repair; marking the repaired data or predicted data as predicted values ​​and assigning a quality score lower than the measured value; when communication is detected to be restored or the data source is restored to normal, stopping the use of predicted values, using measured values ​​as the current data, recording the deviation between the predicted value and the measured value, and feeding the deviation value back to the time series prediction model to update the model parameters.

[0014] In one possible embodiment, a three-tier caching architecture is used to classify and store the data, after quality verification and repair, according to real-time requirements. This includes: writing real-time data acquired at the current sampling time into a first cache layer, which uses an in-memory database for use by fault handling applications with the highest latency requirements; writing statistical data aggregated at the minute level into a second cache layer, which uses a time-series database for use by trend analysis and visualization applications; and archiving the data from the second cache layer to a third cache layer for storage as historical data, which uses a relational database for use by report generation and in-depth analysis applications. The data is archived sequentially from the first cache layer to the second cache layer and from the second cache layer to the third cache layer.

[0015] In one possible embodiment, the push protocol includes at least one of the WebSocket protocol, Message Queuing Telemetry Transport (MQTT), and HyperText Transfer Protocol (HTTP) streaming protocol; on-demand extraction of data from a three-tier caching architecture and push to the client includes: parsing the topic identifier and filtering conditions carried in the data access request; matching the corresponding data topic from a preset topic list according to the topic identifier; extracting the corresponding data from the three-tier caching architecture according to the data topic; filtering the extracted data according to the filtering conditions; establishing a data distribution channel according to the client's subscription information; encapsulating the filtered data according to the push protocol supported by the client; and sending the data to the client through the data distribution channel at a set push interval.

[0016] In one possible embodiment, the access permissions of the client are verified according to a preset role-based access control policy, including: authenticating the data access request to obtain the user's identity information; determining the user's role based on the user's identity information, where the role can be any one of a grid dispatcher, a photovoltaic owner, or an operation and maintenance personnel role; wherein, the grid dispatcher role has a first set of permissions, including reading all data, issuing fault control commands, and performing recovery operations; the photovoltaic owner role has a second set of permissions, including reading its own photovoltaic data, receiving fault alarms, and controlling its own photovoltaic output; and the operation and maintenance personnel role has a third set of permissions, including reading equipment status and fault history, uploading inspection reports, and controlling inspection drones; and verifying whether the operation requested by the data access request falls within the role's permission set according to the permission policy corresponding to the role.

[0017] In one possible embodiment, the interface implementation method for multi-source data fusion in photovoltaic grid-connected distribution networks further includes: extending the definition of dedicated logic nodes for photovoltaic fault analysis, which include: a distributed photovoltaic logic node, containing photovoltaic system identification data objects, photovoltaic system operating status data objects, and photovoltaic system health status data objects; a photovoltaic inverter logic node, containing output power measurement data objects, output voltage measurement data objects, output current measurement data objects, output frequency measurement data objects, and power factor measurement data objects; and a photovoltaic power measurement logic node, containing cumulative power generation data objects, available capacity data objects, and ambient temperature measurement data objects; wherein the distributed photovoltaic logic node, photovoltaic inverter logic node, and photovoltaic power measurement logic node each have a unified and standardized data object name and reference path; correspondingly, the distributed photovoltaic logic node, photovoltaic inverter logic node, and photovoltaic power measurement logic node are used to perform a structured description of data with a unified data format to generate photovoltaic data containing data object names and reference paths.

[0018] Secondly, this application provides an interface implementation device for multi-source data fusion in photovoltaic grid-connected distribution networks, comprising:

[0019] The acquisition module is used to acquire the raw data packets uploaded by devices at each end of the photovoltaic grid-connected distribution network;

[0020] The unified protocol adaptation module is used to identify the communication protocol corresponding to the original data packet based on the device identifier, load the corresponding protocol adapter from the preset protocol adapter library according to the identification result, and convert the original data packet into data with a unified data format according to the data address mapping table of the device through the protocol adapter.

[0021] The data quality control module is used to perform multi-level quality checks on data with a unified data format, generate quality labels for data that fails the checks, and perform automatic repairs.

[0022] The tiered caching module is used to classify and store data that has undergone quality verification and repair according to real-time requirements using a three-tiered caching architecture.

[0023] The data push module is used to respond to the client's data access request, verify the client's access permissions according to the preset role access control policy, and after the verification is successful, extract data from the three-layer caching architecture as needed and push it to the client according to the push protocol supported by the client.

[0024] Thirdly, this application provides an electronic device, including: a processor, and a memory communicatively connected to the processor;

[0025] Memory is used to store instructions executed by the computer;

[0026] A processor for executing computer-executable instructions stored in memory to implement any of the methods of the first aspect.

[0027] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed, are used to implement the method of any one of the first aspects.

[0028] Fifthly, this application provides a computer program product, including a computer program that, when executed, implements the method of any one of the first aspects.

[0029] This application provides an interface implementation method and apparatus for multi-source data fusion in photovoltaic grid-connected distribution networks. The method acquires raw data packets uploaded by devices at each end of the photovoltaic grid-connected distribution network; identifies the communication protocol corresponding to the raw data packets based on device identifiers; loads the corresponding protocol adapter from a pre-set protocol adapter library according to the identification result; converts the raw data packets into data with a unified data format using the protocol adapter according to the data address mapping table corresponding to the device; performs multi-layer quality checks on the data with the unified data format; generates quality tags and performs automatic repair on data that fails the checks; uses a three-layer caching architecture to classify and store the data after quality checks and repair according to real-time requirements; responds to client data access requests, checks client access permissions according to a pre-set role-based access control policy; and, upon successful verification, extracts data from the three-layer caching architecture as needed and pushes it to the client according to the push protocol supported by the client.

[0030] In this process, by acquiring the raw data packets uploaded by devices at each end of the photovoltaic grid-connected distribution network, identifying the corresponding communication protocols based on device identifiers, loading the corresponding protocol adapters, and converting the raw data packets into a unified data format according to the data address mapping table, the impact of protocol differences during the access process of multi-source heterogeneous devices can be reduced and the uniformity of data fusion can be improved. By performing multi-layer quality checks on the unified data, generating quality tags for data that fails the checks and performing automatic repair, the ability to identify and process abnormal data, missing data, and logically conflicting data can be improved, ensuring data quality from the source and thus improving the reliability of multi-source data processing. By adopting a three-layer caching architecture to classify and store the data after quality checks and repairs according to real-time requirements, and performing permission checks based on role-based access control policies when responding to client data access requests, data can be extracted and pushed on demand according to the push protocol supported by the client, which can take into account both real-time response and security management of data access, thereby improving the overall service efficiency and application adaptability of the multi-source data fusion interface of the photovoltaic grid-connected distribution network. Attached Figure Description

[0031] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0032] Figure 1 A flowchart illustrating an interface implementation method for multi-source data fusion in a photovoltaic grid-connected distribution network, provided as an exemplary embodiment of this application;

[0033] Figure 2 A schematic diagram of an interface implementation device for multi-source data fusion in a photovoltaic grid-connected distribution network, provided as an exemplary embodiment of this application;

[0034] Figure 3 A schematic diagram of the structure of an electronic device provided as an exemplary embodiment of this application.

[0035] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0036] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0037] The terms “first,” “second,” etc., used in the specification and claims of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, products, or apparatus.

[0038] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with relevant laws, regulations and standards, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0039] In related technologies, due to the different communication protocol types (such as IEC 61850, DNP3.0, Modbus TCP, DL / T 645, etc.) used by different manufacturers and even different models of the same manufacturer, and the incompatible data address mapping tables of each, existing solutions require the development of corresponding protocol parsing drivers for each device model. This results in extremely low interface program reusability, and adaptation programs must be repeatedly developed whenever a new device is connected, leading to severe deficiencies in system scalability. Secondly, existing solutions lack a unified quality verification and cleaning mechanism for the collected raw data. The collected data is often directly written to the database and used for subsequent fault diagnosis without any validity, integrity, or consistency checks. When communication is interfered with or the device malfunctions, erroneous data may directly lead to false alarms or missed faults, seriously affecting the accuracy and reliability of the fault handling system. Secondly, existing solutions rely on a traditional polling-based data acquisition model, where the interface program sends read commands to each device sequentially at fixed intervals and waits for responses. As the number of connected devices increases, the polling cycle is forced to lengthen. Simultaneously, the single data storage architecture mixes real-time, statistical, and historical data. Fault handling applications need to retrieve data from a large amount of historical records when reading the latest data. Both of these factors contribute to a significant increase in end-to-end latency from the occurrence of a fault to the data being sent to the application layer, making it difficult to meet the stringent millisecond to second-level timeliness requirements of photovoltaic distribution network fault handling. Furthermore, existing interface solutions generally lack fine-grained access control mechanisms for multi-participant scenarios. Different roles, such as grid dispatchers, photovoltaic owners, and maintenance personnel, can access data beyond their respective business scopes, posing security risks of unauthorized access and data leakage. In summary, existing interface solutions have structural defects in four dimensions: access universality, quality reliability, transmission real-time performance, and operational security, making it difficult to adapt to the comprehensive requirements of efficient integration and access of multi-source heterogeneous data in the large-scale development of photovoltaic grid-connected distribution networks.

[0040] Based on the above analysis, this application proposes a set of interface implementation technologies covering the entire chain of data access, quality control, real-time transmission, and security protection, addressing the need for multi-source heterogeneous data fusion access in photovoltaic grid-connected distribution networks. At the data access layer, this concept achieves unified access to multiple heterogeneous communication protocols through a processing mechanism of "protocol identification—dynamic adapter loading—address mapping—unified format conversion," effectively eliminating the system scalability bottleneck caused by the repeated development of protocol drivers due to different equipment models or manufacturers. At the data processing layer, a four-dimensional quality verification rule system is constructed to automatically repair data that fails verification based on the failure type, and a quality tagging mechanism is introduced to achieve refined management of data credibility, ensuring the validity and reliability of data participating in subsequent fault handling from the data source. At the data transmission and distribution layer, a three-layer caching architecture is designed to integrate real-time data, statistical data, and historical data. Data is stored in databases at different performance levels according to real-time requirements, and supplemented by a real-time push mechanism based on topic subscription. This reduces the data access latency of fault handling applications to the millisecond level, effectively improving the real-time performance degradation problem of the traditional polling mode when the number of devices increases. At the system security layer, a role-based access control policy is embedded to assign differentiated data access and operation permissions to different participants, enabling the secure and controlled operation of the data fusion interface in high-concurrency, multi-user scenarios. The above mechanisms work together to form a multi-source data fusion interface technology solution that is fully integrated from the device end to the client end, and has high versatility, high reliability, high real-time performance, and high security.

[0041] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0042] Figure 1 This is a flowchart illustrating an interface implementation method for multi-source data fusion in a photovoltaic grid-connected distribution network, provided as an exemplary embodiment of this application. Figure 1 As shown, the interface implementation method for multi-source data fusion in photovoltaic grid-connected distribution networks includes the following steps:

[0043] S101. Obtain the raw data messages uploaded by each device in the photovoltaic grid-connected distribution network.

[0044] The photovoltaic grid-connected distribution network is used to define the application environment for data access and integration. The access targets are field devices participating in monitoring, metering, protection, or control under grid-connected operation scenarios, specifically including photovoltaic inverters, energy storage converters, smart meters, protection and control devices, combiner box monitoring units, and environmental monitoring terminals. The raw data packets are non-uniformly formatted data carriers output by each device according to its own communication protocol. The packets contain one or more of the following: device address, function code, register address, register value, time information, checksum field, or status bit field. The acquisition process is executed by the interface service process, which is deployed at the site edge gateway, station control server, or dispatch-side access server. After establishing a communication link with the field devices, it receives and uploads data. In one possible embodiment, the communication link can be an Ethernet link, a serial port server forwarding link, an industrial bus gateway link, or a cellular communication link. The interface service process maintains independent access sessions for different link types and, after receiving the byte stream, first writes it to the receive buffer, then completes packet segmentation according to the packet start identifier, length field, or interval timeout rules to form the raw data packets to be processed.

[0045] In specific implementation, data access methods for each terminal device can include two types: proactive uploading and periodic polling. For devices with proactive uploading capabilities, the interface service process listens to a preset port or message channel, records the receiving timestamp, link identifier, and source address information after receiving a message, and sends the complete message to the subsequent identification queue. For devices using master-slave access, the interface service process generates a polling instruction based on the collection period, device address, and register range in the device ledger. After receiving a device response, it extracts the response message as the original data message and stores it in association with the corresponding polling task. In one possible embodiment, the device ledger pre-stores the device's unique number, manufacturer code, model code, communication address, access link, collection period, and affiliated site. The interface service process establishes a message source index based on the device ledger, enabling subsequent steps to reliably locate the message source device. For links where packet splitting or packet merging occurs, the interface service process performs buffer reassembly according to the maximum message length, minimum frame length, and frame verification rules, and only writes the complete message that passes the verification to the receiving queue; for data segments that fail the verification but whose length meets the reassembly conditions, they first enter a temporary buffer to wait for completion, and are marked as invalid reception events after a preset waiting time.

[0046] In this step, although the device identifier is not yet used for formal protocol identification, it can be extracted synchronously during the receiving phase to form a candidate index. The device identifier is used to characterize the source device information of the original data packet. It can directly use the device address, serial number, vendor mark, or logical unit number carried in the packet, or it can use a combination identifier obtained by mapping the access channel and the device ledger within the station. When the original data packet itself does not carry a complete device identifier, the interface service process generates a device identifier based on the receiving port number, slave address, and link binding relationship. Based on this receiving mechanism, the data object entering the system must at least contain the packet byte sequence, receiving timestamp, candidate device identifier value, link source, and packet integrity status, thus constituting the input for subsequent communication protocol identification and adaptation conversion. Based on the above analysis, it can be seen that this step, by uniformly receiving, buffering, segmenting, and associating the source of original packets from multiple sources, allows data from devices of different vendors to be included in the same processing entry point, eliminating the need for separate access via distributed interface programs. This lays the foundation for unified processing of multi-source heterogeneous data at the access level.

[0047] S102. Based on the device identifier, identify the communication protocol corresponding to the original data packet, load the corresponding protocol adapter from the preset protocol adapter library according to the identification result, and convert the original data packet into data with a unified data format through the protocol adapter according to the data address mapping table corresponding to the device.

[0048] The device identifier is used to determine the manufacturer, model, protocol version, or address category of the device from which the message originates; the communication protocol is used to describe the encoding method, field layout, address meaning, and verification rules of the device's message; the protocol adapter library is used to centrally store multiple callable protocol adapter modules; each protocol adapter establishes a corresponding relationship with a type or group of communication protocols; the protocol adapter undertakes the tasks of message parsing and data conversion; the data address mapping table is used to associate the device-side data address with the unified data object within the system; data with a unified data format is a standardized intermediate data object after conversion, which can be encapsulated in a unified way for subsequent quality verification, classified storage, and data push.

[0049] In practice, after the interface service process reads the raw data packets from the receive queue, it first queries the protocol mapping relationship in the device ledger based on the device identifier. When there is a correspondence between the device identifier and a single communication protocol, the target communication protocol is directly determined; when there are multiple candidate communication protocols, the packet characteristics can be combined for judgment to obtain the final identification result. After identification, the system loads the corresponding protocol adapter from the preset protocol adapter library.

[0050] After obtaining the raw data packet, the protocol adapter adapts and converts it according to the data address mapping table corresponding to the device, generating data with a unified data format. In an optional implementation, the original data packet content and the data address mapping table can be further combined to complete field parsing, address mapping, and numerical processing to meet the unified expression requirements within the system. For data with different encoding methods or field organization forms, adaptation processing can be performed according to the corresponding communication protocol.

[0051] After the conversion is complete, the system generates a data set with a unified data format. Data in this set can be bound to sampling time and device identifier, and supplemented with corresponding source information. If the message contains the device's original timestamp, the original timestamp can be used as the sampling time; if the original message does not contain time information, the timestamp received by the interface service process can be used as the sampling time. Based on the above analysis, this step, through device identifier-driven protocol identification, protocol adapter loading, and unified conversion under the constraints of the data address mapping table, converges data from different manufacturers, different address systems, and different encoding methods into a consistent internal expression, thereby eliminating the processing forks in upper-layer services that require separate adaptation to various device messages.

[0052] S103. Perform multi-level quality checks on data with a unified data format, generate quality labels for data that fails the checks, and perform automatic repair.

[0053] The system includes a multi-layered quality verification mechanism for continuous, multi-dimensional, and rule-based testing of uniformly formatted data; quality tags to record the current quality status, anomaly type, and reliability level of the data; and automatic repair to complete or replace data in case of verification failure, ensuring data continuity in subsequent caching and access processes. The verification object is the uniform data set output in step S102, and verification rules can be bound to data object identifiers, device types, and site operating modes. Quality tags include at least a status category field and a score field. The status category field distinguishes between measured valid, missing data repair, anomaly repair, logical correction, and pending review statuses. The score field characterizes the data reliability level; the score of the repaired data is lower than that of the original measured valid data.

[0054] In practice, the system performs multi-layered quality checks on data with a unified data format and generates corresponding quality labels based on the check results. When a check fails, automatic repair processing corresponding to the anomaly is initiated to maintain data continuity and availability. After repair, the system records the repaired value along with the original anomaly value, the basis for repair, and the repair time for traceability. When communication is restored and a valid measured value is obtained again, the system terminates the use of the repair results for that object and switches the quality status back to valid measured value.

[0055] Based on the above analysis, it can be seen that this step, by performing multi-layer quality checks on data in a unified format and automatically repairing abnormal data, ensures that the data subsequently cached and pushed not only has a unified format, but also a traceable quality status and usable continuous values.

[0056] S104. A three-tier caching architecture is adopted to classify and store data that has undergone quality verification and repair according to real-time requirements.

[0057] The three-layer caching architecture is used to hierarchically write quality-controlled data according to real-time access characteristics. The three layers correspond to the first, second, and third cache layers, respectively. The first cache layer can be implemented using an in-memory database, the second cache layer can be implemented using a time-series database, and the third cache layer can be implemented using a relational database. Classifying storage according to real-time requirements means writing data of different purposes within the same batch to different layers based on the data object's usage scenario, access frequency, timeliness requirements, and retention period, while preserving the time and device associations between data objects. The data being written is the verified data with quality tags obtained in step S103. During writing, the numerical value, sampling time, device identifier, data object identifier, quality tag, and repair flag are simultaneously saved.

[0058] In practical implementation, after quality verification and repair, the system first determines the target cache level according to data layering rules. For data directly used in real-time monitoring, fault alarms, and linkage analysis, such as grid connection status, instantaneous voltage and current, power, and fault bits, the system writes them into the first cache layer. The first cache layer uses a key-value structure or a memory time-series structure to store data within the most recent time window. The key can be composed of a combination of site identifier, device identifier, and data object identifier, and the value includes the latest value, the previous value, the update time, and the quality status. For data that needs to retain short-period sequences, it can also be appended to the memory queue by time bucket to support second-level trend queries. For data used in trend analysis, intraday statistics, and equipment performance evaluation, the system writes it into the second cache layer in a time-series format, recording timestamps, tag sets, and value fields, and establishing an index based on site, device, object, and time dimensions. For historical reports, audit logs, and long-term archived data, the system writes the aggregated results or detailed results to the third cache layer. The third cache layer stores site information, equipment information, measurement point information, sampled values, quality labels, repair sources, and batch numbers in a relational table structure to support queries by day, month, or settlement cycle.

[0059] In one possible embodiment, the three-tier caching architecture employs a combination of synchronous and asynchronous write processes. The first caching layer writes are completed within the current processing transaction, ensuring the latest data can immediately respond to real-time access requests. The second and third caching layers are asynchronously written to the database by background write tasks based on batch queues. These background tasks read data from the buffer queue in chronological order, first writing to the time-series database, and then generating archived records according to a preset archiving period and writing them to the relational database. To maintain data consistency across the three layers, each data entry carries a globally unique batch identifier and a sampling timestamp. The latest value in the first caching layer uses the same batch identifier as the corresponding time-series point in the second caching layer, while the third caching layer retains the source batch range. For repaired data, quality tags and repair markers are synchronously written across all three layers, ensuring that the client can perceive that the data is not the original measured value regardless of which layer it retrieves from. If the same object receives a subsequently replenished measured value, the system locates the existing record based on the device identifier, data object identifier, and sampling time, performs version updates or adds markers in the second and third caching layers, and refreshes the latest status in the first caching layer.

[0060] The tiered rules in this step can be directly linked to real-time parameters. For example, data with a sampling period of no more than 5 seconds and used for alarm judgment directly enters the first cache layer; data with a sampling period between 5 seconds and 15 minutes and required to form a continuous curve enters the second cache layer; data that needs to be frozen daily, statistically analyzed monthly, or tracked through work orders and requires long-term storage enters the third cache layer. This parameter range is used to limit the read / write load and retention depth of different layers, ensuring that the first cache layer only retains short-term, high-frequency data, the second cache layer handles medium-term curve queries, and the third cache layer handles long-term detailed and statistical storage. Based on the above analysis, this step uses a three-tiered caching architecture consisting of an in-memory database, a time-series database, and a relational database to separate the data paths for real-time monitoring and historical queries, reducing resource contention between different access scenarios and maintaining synchronous storage of quality tags across all layers. It should be understood that the above example is for demonstration purposes only and is not a limitation.

[0061] S105. In response to the client's data access request, verify the client's access permissions according to the preset role access control policy. After the verification is successful, extract data from the three-layer caching architecture as needed and push it to the client according to the push protocol supported by the client.

[0062] In this application, the client is the terminal entity that initiates data access and receives push results. It can be a dispatch workstation, a site monitoring terminal, an operation and maintenance mobile terminal, or an owner-side portal. The client's data access request triggers the permission verification and data extraction process. The request content includes at least the client's identity information, the target site or equipment scope, the data object scope, the time range, real-time requirements, and supported push protocols. Role-based access control policies restrict the data and operational scope that the client can access based on its assigned role. Roles can include grid dispatchers, photovoltaic owners, and operation and maintenance personnel. The push protocols supported by the client limit the data return method, specifically using WebSocket, MQTT, or HTTP streaming protocols. The system negotiates and determines the final push protocol based on the client's capabilities and organizes the returned data accordingly.

[0063] In practice, after a client initiates an access request, the access service first verifies the client's identity credentials, which can be a session token, certificate digest, or signature digest. Once identity verification is successful, the permission service maps the client's identity to a role and loads the corresponding access control policy. The role-based access control policy includes at least the allowed set of sites, device categories, measurement points, operation type, and time range restrictions. The permission service matches the target data conditions in the access request against the policy item by item. For example, a grid dispatcher role can access real-time power and alarm information from multiple sites within their dispatch jurisdiction; a photovoltaic owner role can only access data from their own sites; and an operations and maintenance personnel role can access device-level status variables and maintenance-related historical records but cannot access sites beyond their authorized access. If the request exceeds the permission set, the system returns a rejection result and records an audit log; if the verification passes, a query context with the permission scope is generated to enter the data extraction stage.

[0064] During the data extraction phase, the system selects a data source from a three-tiered caching architecture based on the real-time requirements and time range specified in the client's request. For real-time subscription requests, the system extracts the latest value or recent window data from the first caching layer; for trend query requests, the system reads data points from the second caching layer in time series order; and for historical report or audit query requests, the system reads detailed or statistical records from the third caching layer. On-demand extraction is not only based on tier selection but also tailored to the subscription topic and filtering conditions. Subscription topics can be limited to the grid-connected power of a specific site, the fault status of a particular inverter, or the daily power generation of a certain type of equipment. Filtering conditions can include time intervals, quality status, equipment grouping, and a whitelist of measurement points. The system retains the quality label field during extraction, enabling clients to distinguish between measured values ​​and repaired values. For cross-tier requests, such as those requiring both the latest value and the trend curve for the most recent 24 hours, the system retrieves data from the first and second caching layers respectively, merges the data within the response channel, and organizes it chronologically.

[0065] During the push phase, data is encapsulated and sent according to the push protocol supported by the client. When the client supports the WebSocket protocol and the request is a continuous subscription, the system establishes a long connection and pushes the filtered real-time data according to object change events. When the client supports MQTT, the system publishes data to the corresponding topic channel according to the subscribed topic, and the client receives it through topic subscription. When the client uses the HTTP streaming protocol, the system maintains a streaming response and continuously writes data fragments that meet the conditions during the connection's existence. To ensure data consistency under different protocols, the system encapsulates the extracted results into a unified response structure before pushing, which includes at least the site identifier, device identifier, data object identifier, sampling time, value, unit, and quality label, and then converts it into the corresponding transmission format by the protocol adaptation layer. For real-time continuous push scenarios, the system only triggers incremental pushes when the data value changes, the quality status changes, or the maximum sending interval is reached. For historical query scenarios, the system returns data in batches according to the request and closes the short connection or ends the stream after the return is completed. After the push is completed, the system records the request identifier, extraction level, number of returned items, and protocol type to form an access audit log.

[0066] Based on the above analysis, this step combines role-based access control with hierarchical cache extraction. After the permissions are granted, the corresponding level of data is returned according to the protocol supported by the client. This allows the same set of integrated data to be output to different roles and terminals in a controlled manner, while maintaining the separation of processing paths between real-time monitoring access and historical query access.

[0067] The interface implementation method for multi-source data fusion in photovoltaic grid-connected distribution networks provided in this application embodiment obtains the original data packets uploaded by devices at each end of the photovoltaic grid-connected distribution network, identifies the corresponding communication protocol based on device identifiers, loads the corresponding protocol adapter, and converts the original data packets into a unified data format according to the data address mapping table. This reduces the impact of protocol differences during the access process of heterogeneous devices from multiple sources and improves the uniformity of data fusion. By performing multi-layer quality verification on the unified data, generating quality tags and performing automatic repair on data that fails the verification, the method improves the identification and processing capabilities of abnormal data, missing data, and logically conflicting data, ensuring data quality from the source and thus improving the reliability of multi-source data processing. By adopting a three-layer caching architecture to classify and store the data after quality verification and repair according to real-time requirements, and performing permission verification based on role-based access control policies when responding to client data access requests, the method extracts and pushes data on demand according to the push protocol supported by the client. This balances real-time response and security management of data access, thereby improving the overall service efficiency and application adaptability of the multi-source data fusion interface for photovoltaic grid-connected distribution networks.

[0068] In some implementations, the communication protocol includes at least one of IEC 61850, DNP3.0, Modbus TCP, and DL / T 645.

[0069] In this embodiment, when the system connects to a photovoltaic inverter, energy storage device, smart meter, or protection device, it first identifies the communication protocol based on the device identifier, then loads the protocol adapter matching the protocol from the protocol adapter library, and parses and maps the message content to fields. IEC 61850 is used for data communication with in-station automation equipment. The system can use this to identify logical nodes, data objects, and data attributes in the message and convert them into a unified data format. DNP3.0 is used for remote monitoring message access in distribution automation scenarios. The system uses this to parse object groups, change flags, and timestamp information. ModbusTCP is used for register-type data access via Ethernet transmission. The system completes reading and conversion based on register addresses and function codes. DL / T 645 is used for data access of smart meter devices. The system can parse electricity, power, and voltage data according to their frame format and data identifier and map them to unified fields. All of the above protocols can enter subsequent unified verification and caching processing through the same access interface.

[0070] In practical implementation, the protocol adapter library can pre-store parsing templates, data address mapping tables, and data type conversion rules corresponding to each communication protocol. Once the system identifies that a device uses any of these communication protocols, it calls the corresponding template to complete frame verification, field truncation, and numerical conversion. Using this approach, raw data packets from devices of different sources can be converted into a consistent data structure, facilitating subsequent quality verification, categorized storage, and access / push processing, thus maintaining uniformity and scalability for multi-source heterogeneous device access.

[0071] In some embodiments, the original data packet is converted into data with a unified data format according to the data address mapping table corresponding to the device. This includes: parsing the original data packet to extract the register address and register value; mapping the register address to an internal unified data object identifier according to the data address mapping table; converting the register value to a value in engineering units according to a preset unit conversion factor in the data address mapping table; and encapsulating the data object identifier and the value in engineering units into data with a unified data format according to a preset unified data structure.

[0072] The original data message can be an information message carrying register address and register value in Modbus TCP, DL / T645 or other message formats. The message parsing module completes field identification according to the message header, function code, byte length and data field, and outputs the parsed address field and value field respectively.

[0073] In its implementation, after reading the raw data message, the system uses the register address in the data field as the lookup key to access the data address mapping table, obtains the corresponding data object identifier, and then performs a conversion based on the register value and a unit conversion factor. The conversion relationship can be multiplication, division, or linear conversion with offset, to convert the raw measurement value into a value in the engineering unit system. The preset unified data structure can include the data object identifier, the value in the engineering unit system, a timestamp, and a device identifier. The data object identifier and the value in the engineering unit system are encapsulated into a data entity with a unified data format for easy subsequent verification, storage, and push. The unified data structure can be implemented using key-value pairs, structures, or message objects. In practical applications, other models or field organization methods can also be selected for this structure, which is not limited in this application.

[0074] This scheme first extracts register addresses and values, then standardizes addresses and dimensions using a data address mapping table, and finally generates data objects that can be processed uniformly. As a result, heterogeneous register information in messages from different devices is converted into a consistent data representation, enabling subsequent modules to perform quality checks, cache organization, and client push based on the same data structure.

[0075] By adopting this implementation method, the data object identifier eliminates the differences in address systems of different devices, and the numerical values ​​under the engineering unit system eliminate the differences in the original measurement standards, making the unified data format comparable and integrable, and reducing the dependence of upper-layer services on device protocol details, thereby improving the stability of multi-source data access and unified processing.

[0076] Based on the above embodiments, further, in some embodiments, multi-layer quality checks are performed on data with a unified data format, including: performing a range check on the data with a unified data format to verify whether the data value of the data with a unified data format is within a preset physical range; performing a rate of change check on the data with a unified data format to verify whether the rate of change between the data value at the current sampling time and the data value at the previous sampling time exceeds a preset maximum allowable rate of change threshold; performing a consistency check on the data with a unified data format to verify whether the logical relationship between the data value of the data with a unified data format and the data value of the associated data point meets preset logical constraints; performing an integrity check on the data with a unified data format to verify whether the data frame structure corresponding to the data with a unified data format is complete and whether any required fields are missing; and generating corresponding quality labels based on the results of each check.

[0077] In the specific implementation, after the system completes the unified data format encapsulation, it sends the data with the unified data format to the quality verification module. This module can be implemented by the processor executing preset verification instructions. For each data record, it sequentially reads its numerical field, sampling timestamp, associated data point identifier and data frame structure information, and calls the preset range threshold table, maximum allowable change rate threshold table, logical constraint table and integrity verification rules to complete the comparison. During the specific verification process, the system first performs a range check on the data values, comparing them with a preset physical range (e.g., photovoltaic output should be between 0 and rated capacity). If the range is exceeded, it is marked as "range abnormality". Second, the system extracts the data values ​​at the current sampling time and the previous sampling time, calculates the rate of change between the two, and if it exceeds the preset maximum allowable rate of change threshold, it is marked as "rate of change abnormality". Third, the system performs a consistency check based on the physical logical relationship between related data points, such as verifying whether active power, reactive power, and apparent power satisfy the sum of squares relationship. If the logical relationship does not meet the preset constraints, it is marked as "consistency abnormality". Finally, the system performs an integrity check on the data frame, confirming whether the frame structure is complete and whether any required fields are missing. If any are missing, it is marked as "integrity abnormality". When any verification item fails, the system generates a corresponding quality label for the data object. The quality label can record status information such as "range abnormality", "rate of change abnormality", "consistency abnormality" or "integrity abnormality" and the reason for failure, which can be used as a basis for subsequent automatic repair, filtering or downgrading. In practical applications, the quality verification module can be deployed on edge gateways, station control hosts, or central servers; this application does not limit this.

[0078] Using the above method, data with a unified data format can undergo multi-dimensional quality verification before tiered caching storage. The generated quality labels can accurately reflect the four different types of data anomaly states, enabling abnormal data to be identified in a timely manner and enter the subsequent automatic repair processing chain. Since range checks, rate of change checks, consistency checks, and integrity checks correspond to different dimensions of quality constraints, this verification method can improve the accuracy of data quality identification and provide a reliable basis for subsequent automatic repair and trusted data push.

[0079] In some embodiments, for data that fails quality verification, automatic repair is performed according to a preset repair strategy, including: for data that fails the check because the data value exceeds a preset physical range or because the rate of change exceeds a preset maximum allowable rate of change threshold, interpolation is used to generate repair data; for data that fails the check because a required field is missing or the data frame structure is incomplete, a preset time series prediction model is used to generate predicted data to fill in the missing values; for data that fails the check because the logical relationship does not meet the logical constraints, the theoretical value of the related data point as the dependent variable is calculated from the related data point as the independent variable based on the physical constraint relationship between the related data points involved in the logical constraints, and the theoretical value is used to replace the corresponding measured value for repair; the repaired data or predicted data is marked as predicted value and assigned a quality score lower than the measured value; when communication is detected to be restored or the data source is restored to normal, the predicted value is stopped, the measured value is used as the current data, and the deviation value between the predicted value and the measured value is recorded, and the deviation value is fed back to the time series prediction model to update the model parameters.

[0080] In the specific implementation, after completing multi-layer quality verification, for data that fails range check or rate of change check, the system first reads the valid data points and their timestamps from adjacent time points, then calculates the interpolation position of the time point to be repaired based on the sampling period, and uses linear interpolation for single variables and spline interpolation for multivariables to generate repaired data. For data with missing required fields or incomplete frame structure, the system extracts continuous samples from the historical sequence cache of the same device, inputs them into a preset time series prediction model, outputs the predicted values ​​corresponding to the missing fields, and backfills them into a unified data structure. For data that fails consistency check, the system determines the functional relationship between the independent and dependent variables based on preset logical constraints, then calculates the theoretical value from the measured associated data points, and replaces the abnormal measured values ​​with the theoretical value to form the repaired unified data.

[0081] Once the repair results are generated, the system writes them into the quality label field and assigns a score lower than the measured value. For example, a quality score of 0.8 is assigned to repaired data generated by interpolation and physical law inference methods, and a quality score of 0.6 is assigned to predicted data generated by time series forecasting. The system also retains the original outliers and their sources of repair (such as anomaly type identifiers like "range anomaly," "rate of change anomaly," and "communication interruption") for verification after communication is restored. After communication or the data source returns to normal, the system overwrites the predicted values ​​with the measured values ​​from the latest message and calculates the deviation between the predicted and measured values. This deviation can be used as the mean squared error or absolute error input into the time series forecasting model to update the model parameters.

[0082] The following is a specific application example illustrating the above automatic repair process: A photovoltaic grid-connected point experiences a data stream interruption due to a communication link failure. After detecting that the grid-connected point has not received valid data packets for several consecutive sampling periods, the system marks the data point as "communication interrupted" and triggers the automatic repair process. The system extracts the output data from the most recent N sampling times from the device's historical sequence cache as training samples and uses a time series prediction model, such as the Autoregressive Integrated Moving Average (ARIMA) model, to generate temporary substitute data during the communication interruption. The system marks the substitute data as "predicted values" and sets a quality score of 0.6 (lower than the measured value's 0.9) to clearly distinguish between predicted data and actual collected data in subsequent data processing. When the communication link is restored and the system receives the latest measured value from the grid-connected point again, it automatically stops using the predicted value, switches back to the measured value as the current data, and records the deviation between the predicted value and the measured value during the communication interruption. This deviation is fed back to the time series prediction model for online optimization and updating of model parameters.

[0083] In this way, the system can maintain continuous and usable data output during data anomalies and complete model self-correction after data recovery, thereby improving the consistency and reliability of subsequent missing data completion and anomaly repair.

[0084] In some embodiments, a three-layer caching architecture is used to classify and store the data after quality verification and repair according to real-time requirements, including: writing real-time data acquired at the current sampling time into a first cache layer, which uses an in-memory database for use by fault handling applications with the highest latency requirements; writing statistical data aggregated at the minute level into a second cache layer, which uses a time-series database for use by trend analysis and visualization applications; archiving the data from the second cache layer to a third cache layer for storage as historical data, which uses a relational database for use by report generation and deep analysis applications; and archiving the data sequentially from the first cache layer to the second cache layer and from the second cache layer to the third cache layer.

[0085] In actual operation, the unified data after quality verification and repair is first written to the first cache layer according to the current sampling time. This first cache layer uses an in-memory database, which can support millisecond-level data read and write. Therefore, fault handling applications with the highest latency requirements can directly access the latest real-time data stored therein, enabling rapid response after a fault occurs. The system aggregates the real-time data in the first cache layer at the minute level according to a preset sampling period, forming minute-aggregated statistical data, which is then written to the second cache layer. This second cache layer uses a time-series database, which can efficiently store and query statistical data organized by time series. Therefore, trend analysis and visualization applications can obtain minute-level change trends through this layer. Subsequently, the statistical data that has been statistically confirmed in the second cache layer is archived to the third cache layer according to a preset archiving period, forming historical data. This third cache layer uses a relational database, which can support complex queries and long-term storage. Therefore, report generation and in-depth analysis applications can obtain complete historical data through this layer. The above data is archived sequentially from the first cache layer to the second cache layer and from the second cache layer to the third cache layer, forming a hierarchical data flow path, ensuring that the data in each layer is utilized most effectively within its corresponding real-time window. Through the above mechanism, fault handling applications can directly access the latest data in the first cache layer, trend analysis and visualization applications can access minute statistics in the second cache layer, and report generation and in-depth analysis applications can call historical data in the third cache layer. Each layer undertakes data management tasks at three different time-sensitivity levels: millisecond, minute, and persistent, thereby enabling data with different real-time requirements to be carried in a layered manner.

[0086] This three-layer caching architecture separates real-time data, statistical data, and historical data, and archives the data in a hierarchical order. This enables the first caching layer to maintain a fast access channel for high-time data, the second caching layer to maintain the ability to aggregate access to time-series data, and the third caching layer to maintain the ability to preserve the structured and long-term storage of all historical data. This allows for the classification, organization, and unified retrieval of data that has undergone quality verification and repair.

[0087] In some embodiments, the push protocol includes at least one of WebSocket, MQTT, and HTTP streaming protocols; on-demand data extraction from a three-tier caching architecture and push to the client includes: parsing the topic identifier and filtering conditions carried in the data access request; matching the corresponding data topic from a preset topic list according to the topic identifier; extracting the corresponding data from the three-tier caching architecture according to the data topic; filtering the extracted data according to the filtering conditions; establishing a data distribution channel according to the client's subscription information; encapsulating the filtered data according to the push protocol supported by the client; and sending the data to the client through the data distribution channel at a set push interval.

[0088] In practice, data access requests can carry filtering conditions such as topic identifier, time range, device identifier, data type, and threshold conditions. After receiving the request, the server first parses the topic identifier and performs a match in a preset topic list. If a matching data topic is found, the target record in the first, second, or third cache layer is located based on the data topic, and the corresponding data is extracted according to the time range and data type indicated in the request. Subsequently, the system filters the extracted data according to the filtering conditions, such as removing data that does not meet the threshold range, status flag, or time constraint, and selecting data that meets the conditions as data to be pushed.

[0089] The client's subscription information may include the subscription topic, protocol type, receiving frequency, and push window. The system establishes a corresponding data distribution channel based on the subscription information and encapsulates the data to be pushed according to the protocol types supported by the client. If the client supports the WebSocket protocol, the data is encapsulated into message frames and sent via a long connection; if the client supports MQTT, the data is organized into a topic-published message and sent via the publish-subscribe link; if the client supports the HTTP streaming protocol, the data is written to a continuous response stream and the connection is maintained until the end of this push. The push interval can be configured in seconds or minutes. For example, in fault handling scenarios, the push interval can be configured to 100 milliseconds to meet real-time requirements; in regular monitoring scenarios, the push interval can be configured in seconds or minutes to balance system resource consumption and data timeliness requirements. The system periodically sends filtered data according to this interval.

[0090] For example, when a fault occurs in the distribution network, the system needs to push real-time data to multiple clients simultaneously. The dispatch center client subscribes to topics such as fault events, photovoltaic status, and switch changes, and receives data via the WebSocket protocol. The mobile application client subscribes to topics such as affected users and recovery progress, and receives data via MQTT. The system locates the corresponding data topic in the three-layer caching architecture based on the topic identifiers subscribed to by each client, extracts the latest real-time data from the first caching layer, and filters it according to the filtering conditions subscribed to by the client. For the dispatch center client, the system encapsulates the filtered data into message frames according to the WebSocket protocol and sends them through the established persistent long-connection channel at a push interval of 100 milliseconds. For the mobile application client, the system organizes the data into topics and publishes messages according to the MQTT protocol, distributing them through the publish-subscribe link at the same push interval. Actual testing shows that this push mechanism can maintain a data push latency of less than 200 milliseconds even with more than 1000 concurrent connections, ensuring that fault information reaches relevant personnel within seconds.

[0091] By adopting the above method, during the operation, the topic identifier completes the accurate matching of data topics in the preset topic list and the location of target data in the three-layer caching architecture; the filtering conditions complete the secondary screening of the extracted data; the subscription information completes the establishment of the client distribution channel and the selection of the supported push protocol; and the push interval completes the control of the data sending rhythm. Through the above four links, a complete push link from request parsing to targeted distribution is formed, so that different real-time data in the three-layer caching architecture can be pushed in a targeted manner according to the push protocol supported by the client.

[0092] In some embodiments, client access permissions are verified according to a preset role-based access control policy, including: authenticating the data access request to obtain the client's user identity information; determining the user's role based on the user identity information, where the role can be any one of a grid dispatcher, a photovoltaic owner, or an operation and maintenance personnel role; wherein, the grid dispatcher role has a first set of permissions, including reading all data, issuing fault control commands, and performing recovery operations; the photovoltaic owner role has a second set of permissions, including reading its own photovoltaic data, receiving fault alarms, and controlling its own photovoltaic output; and the operation and maintenance personnel role has a third set of permissions, including reading equipment status and fault history, uploading inspection reports, and controlling inspection drones; and verifying whether the operation requested by the data access request falls within the role's permission set according to the permission policy corresponding to the role.

[0093] In this implementation, the first set of permissions corresponding to the grid dispatcher role can be configured to cover global monitoring data, fault alarm data, control commands, and recovery records; the second set of permissions corresponding to the photovoltaic owner role can be limited to the power generation, inverter status, alarm information, and output adjustment operations of their respective photovoltaic power stations; and the third set of permissions corresponding to the maintenance personnel role can be limited to equipment status, fault history, inspection records, and control commands for inspection drones. Upon receiving a data access request from a client, the system first authenticates the requester using at least one of digital certificate authentication, security token authentication, or multi-factor authentication. After successful authentication, the system obtains the client's user identity information. Subsequently, the system determines the user's role based on the user's identity information. When determining the requested operation, the system compares the requested operation code with the current role's permission entries item by item. If the operation code matches an authorized item in the permission set, access permission is granted; otherwise, a rejection response is returned, and an audit log is recorded. Furthermore, during communication between the client and server, the system uses Transport Layer Security (TLS) to encrypt the data channel, ensuring the confidentiality and integrity of the data during transmission.

[0094] Through the above methods, the system can complete role identification based on user identity information and constrain operations such as data reading, control distribution, and maintenance uploading according to the permission sets of different roles. At the same time, combined with identity authentication mechanism and TLS encrypted communication, the system ensures operational security from three levels: identity authentication, access control, and data transmission. This enables fine-grained control of client access permissions, ensures clear operational boundaries for the three types of users—schedule, owner, and operation and maintenance—on the same data platform, and facilitates subsequent auditing, tracing, and access management.

[0095] In some embodiments, the interface implementation method for multi-source data fusion in photovoltaic grid-connected distribution networks further includes: extending the definition of dedicated logic nodes for photovoltaic fault analysis, which include: a distributed photovoltaic logic node, containing photovoltaic system identification data objects, photovoltaic system operating status data objects, and photovoltaic system health status data objects; a photovoltaic inverter logic node, containing output power measurement data objects, output voltage measurement data objects, output current measurement data objects, output frequency measurement data objects, and power factor measurement data objects; and a photovoltaic power measurement logic node, containing cumulative power generation data objects, available capacity data objects, and ambient temperature measurement data objects. The distributed photovoltaic logic node, photovoltaic inverter logic node, and photovoltaic power measurement logic node each have a unified and standardized data object name and reference path. Correspondingly, the distributed photovoltaic logic node, photovoltaic inverter logic node, and photovoltaic power measurement logic node are used to structurally describe data with a unified data format, generating photovoltaic data containing data object names and reference paths.

[0096] In practical applications, distributed photovoltaic (PV) logic nodes, PV inverter logic nodes, and PV power measurement logic nodes can be pre-installed in a unified data model after protocol adaptation. These logic nodes follow the naming conventions of the IEC 61850-7-420 standard, each with a unified and standardized data object name and reference path. They serve as structured templates for mapping a unified data format to dedicated PV fault analysis logic nodes. Distributed PV logic nodes correspond to PV system identifiers, operating status, and health status; PV inverter logic nodes correspond to output power, output voltage, output current, output frequency, and power factor; and PV power measurement logic nodes correspond to cumulative power generation, available capacity, and ambient temperature. When the original message is parsed and converted to a unified data format, the system retrieves the corresponding logic node based on the data object identifier and then writes the values ​​into the data fields bound to the reference path, thus forming PV data that can be directly called by upper-layer analysis modules. In this way, PV operating parameters from different manufacturers and different protocol sources can be expressed in the same structure, facilitating joint comparison of operating status, health status, inverter electrical parameters, and environmental correlation parameters, and enabling fault identification, anomaly alarms, and trend analysis.

[0097] With this structure, the data objects required for photovoltaic fault analysis have unified data object names and paths, which reduces mapping deviations caused by semantic inconsistencies across devices and improves the consistency and retrieval of data organization. Since photovoltaic data is output in a structured manner, and the distributed photovoltaic logical nodes, photovoltaic inverter logical nodes, and photovoltaic power measurement logical nodes each have unified and standardized data object names and reference paths, the fault analysis module can directly associate operating status, health status, and electrical parameters by data object name. This provides consistent data input for fault identification, anomaly alarms, and trend analysis in multi-source data fusion scenarios, thereby improving the stability and accuracy of diagnostic and statistical processing.

[0098] In practical implementation, taking the connection of photovoltaic inverters from different manufacturers such as Manufacturer A, Manufacturer B, and Manufacturer C as an example, the system first automatically identifies the communication protocol type and address mapping differences supported by each inverter through device identification. For example, although Manufacturer A and Manufacturer B both use the Modbus TCP protocol, their register address definitions and unit conversion coefficients are different. Subsequently, the system loads the corresponding Modbus adapter from the protocol adapter library according to the identification results and reads the specific data address mapping configuration file of each manufacturer. Through the adapter, it periodically collects real-time data such as the inverter's output power, voltage, current, and power factor, and converts the original register values ​​into standardized engineering unit data according to the mapping relationship (for example, mapping register values ​​0-65535 to active power of 0-1000kW). During and after the collection, the system performs range checks (for example, checking whether the power value is within the range of 0 to the rated capacity) and rate of change checks on the data to ensure the validity of the data entering the subsequent processing link. After the checks are passed, the data is written to the real-time cache layer in the three-layer cache architecture in a unified data format for use by the upper-layer monitoring and fault handling system. Throughout the entire access process, new vendor devices only need to add corresponding address mapping configuration files, without the need to redevelop protocol parsing drivers, which significantly improves the reusability of interface programs. Actual testing has verified that the above technical solution enables unified access for devices from multiple vendors, reducing interface development workload by approximately 70% compared to traditional solutions, controlling protocol conversion time to within 100ms, and significantly improving system access versatility and development efficiency.

[0099] In summary, this application has at least the following advantages:

[0100] I. By constructing a unified protocol adaptation framework, this application supports unified access for multiple communication protocols such as IEC 61850, DNP3.0, Modbus TCP, and DL / T 645. Employing a dynamic adapter loading mechanism, it allows new devices to be adapted simply by adding a corresponding address mapping configuration file, eliminating the need to develop separate protocol parsing drivers for different device models. Compared to related technologies that require separate adaptation programs for each device, this application significantly reduces the impact of protocol differences in multi-source heterogeneous device access, greatly reduces interface development workload, and effectively improves system scalability and access universality.

[0101] Second, by utilizing a built-in four-dimensional quality inspection rule base, the system performs range checks, rate of change checks, consistency checks, and integrity checks on the input data stream. For different types of check failures, it automatically repairs the data using interpolation, time series forecasting, or physical law inference methods, while simultaneously generating quality labels to record abnormal data states. Compared to related technologies that directly upload raw data without verification, this application effectively improves the identification and processing capabilities of abnormal, missing, and logically conflicting data, ensuring data quality from the source and guaranteeing that the data used for fault diagnosis possesses sufficient validity, completeness, and reliability.

[0102] Third, by designing a three-tiered caching architecture consisting of an in-memory database (for millisecond-level real-time data), a time-series database (for minute-level statistical data), and a relational database (for full historical data), and combining it with a topic-based subscription-based real-time push mechanism, high-real-time applications can directly obtain the latest data from the first caching layer without having to search through a large amount of historical data. Simultaneously, the server proactively pushes matching data based on the topics subscribed to by the client, reducing the communication overhead caused by repeated client requests. Compared to the traditional polling-based collection and single-storage architecture implementations in related technologies, this application can significantly reduce data access latency, support large-scale concurrent connections and low-latency data push, thereby meeting the stringent requirements of millisecond- to second-level data timeliness in fault handling scenarios.

[0103] Fourth, by implementing a role-based access control policy, differentiated data access and operation permissions are assigned to three different roles: grid dispatchers, photovoltaic owners, and operation and maintenance personnel. Identity verification is performed using digital certificates, security tokens, or multi-factor authentication, and data channels are encrypted using transport layer security protocols. Compared to existing interface solutions that generally lack fine-grained access control mechanisms, this invention can clearly isolate the operational boundaries of different participants, effectively preventing unauthorized access and misoperation. It ensures the secure and controlled operation of data for dispatchers, owners, and operation and maintenance users on the same data platform, and facilitates subsequent auditing, tracing, and access control.

[0104] Fifth, by extending the definition of distributed photovoltaic (PV) logic nodes, PV inverter logic nodes, and PV power measurement logic nodes based on the IEC 61850-7-420 standard logic nodes, PV operating parameters from different manufacturers and different protocol sources can be expressed in the same structured model. Structured description and interaction of PV data are achieved through standardized data object names and reference paths. With this structure, the data objects required for PV fault analysis have a unified data organization method, reducing mapping deviations caused by semantic inconsistencies across devices, improving data organization consistency and retrieval, and enabling upper-level fault analysis modules to directly associate operating status, health status, and electrical parameters by data object name for joint comparison and diagnosis, thereby improving the stability and accuracy of subsequent diagnosis and statistical processing.

[0105] In summary, this application, through the combined use of the aforementioned technical means, systematically improves the multi-source data fusion interface of photovoltaic grid-connected distribution networks from five dimensions: protocol adaptation, quality control, real-time transmission, security protection, and data fusion structure. It effectively improves the shortcomings of existing interface solutions in terms of access universality, quality reliability, transmission real-time performance, and operational security, and provides a complete interface solution for intelligent fault handling of photovoltaic grid-connected distribution networks that combines high universality, high reliability, high real-time performance, and high security.

[0106] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0107] Figure 2 This is a schematic diagram of an interface implementation device for multi-source data fusion in a photovoltaic grid-connected distribution network, provided as an exemplary embodiment of this application. Figure 2 As shown, the interface implementation device 20 for multi-source data fusion in photovoltaic grid-connected distribution networks includes an acquisition module 21, a unified protocol adaptation module 22, a data quality control module 23, a hierarchical caching module 24, and a data push module 25, wherein:

[0108] The acquisition module 21 is used to acquire the raw data packets uploaded by the equipment at each end of the photovoltaic grid-connected distribution network;

[0109] The unified protocol adaptation module 22 is used to identify the communication protocol corresponding to the original data packet based on the device identifier, load the corresponding protocol adapter from the preset protocol adapter library according to the identification result, and convert the original data packet into data with a unified data format through the protocol adapter according to the data address mapping table corresponding to the device.

[0110] Data quality control module 23 is used to perform multi-level quality checks on data with a unified data format, generate quality labels for data that fails the checks, and perform automatic repair.

[0111] The tiered caching module 24 is used to classify and store data that has undergone quality verification and repair according to real-time requirements using a three-tiered caching architecture.

[0112] The data push module 25 is used to respond to the client's data access request, verify the client's access permissions according to the preset role access control policy, and after the verification is successful, extract data from the three-layer caching architecture as needed and push it to the client according to the push protocol supported by the client.

[0113] In one possible implementation, the unified protocol adaptation module 22 can be specifically used to: parse the original data message and extract the register address and register value; map the register address to an internally unified data object identifier according to the data address mapping table; convert the register value to a value in engineering units according to the preset unit conversion coefficient in the data address mapping table; and encapsulate the data object identifier and the value in engineering units into data with a unified data format according to the preset unified data structure.

[0114] In one possible embodiment, the data quality control module 23 may be specifically used to: perform a range check on data with a unified data format to verify whether the data value of the data with the unified data format is within a preset physical range; perform a rate of change check on data with a unified data format to verify whether the rate of change between the data value at the current sampling time and the data value at the previous sampling time exceeds a preset maximum allowable rate of change threshold; perform a consistency check on data with a unified data format to verify whether the logical relationship between the data value of the data with the unified data format and the data value of the associated data point meets preset logical constraints; perform an integrity check on data with a unified data format to verify whether the data frame structure corresponding to the data with the unified data format is complete and whether there are any missing required fields; and generate corresponding quality labels based on the results of each check.

[0115] In one possible embodiment, the data quality control module 23 can also be used to: generate repair data using interpolation for data that fails to be checked due to data values ​​exceeding a preset physical range or changes exceeding a preset maximum allowable change rate threshold; generate predicted data using a preset time series prediction model to fill in missing values ​​for data that fails to be checked due to missing required fields or incomplete data frame structure; generate predicted data using a preset time series prediction model to fill in missing values ​​for data that fails to be checked due to logical relationships not meeting logical constraints, calculate the theoretical value of the related data point as the dependent variable from the related data point as the independent variable based on the physical constraint relationship between the related data points involved in the logical constraints, and replace the corresponding measured value with the theoretical value for repair; mark the repaired data or predicted data as predicted values ​​and assign a quality score lower than the measured value; when communication is detected to be restored or the data source is restored to normal, stop using the predicted value, use the measured value as the current data, record the deviation between the predicted value and the measured value, and feed the deviation value back to the time series prediction model to update the model parameters.

[0116] In one possible embodiment, the hierarchical caching module 24 can be specifically used to: write real-time data acquired at the current sampling time into a first cache layer, the first cache layer using an in-memory database for use by fault handling applications with the highest latency requirements; write statistical data aggregated at the minute level into a second cache layer, the second cache layer using a time-series database for use by trend analysis and visualization applications; archive data from the second cache layer to a third cache layer for storage as historical data, the third cache layer using a relational database for use by report generation and in-depth analysis applications; and archive data sequentially from the first cache layer to the second cache layer and from the second cache layer to the third cache layer.

[0117] In one possible embodiment, the push protocol includes at least one of WebSocket, MQTT, and HTTP streaming protocols; the data push module 25 can be specifically used to: parse the topic identifier and filtering conditions carried in the data access request, match the corresponding data topic from the preset topic list according to the topic identifier, and extract the corresponding data from the three-layer caching architecture according to the data topic; filter the extracted data according to the filtering conditions; establish a data distribution channel according to the client's subscription information, encapsulate the filtered data according to the push protocol supported by the client, and send it to the client through the data distribution channel at a set push interval.

[0118] In one possible embodiment, the data push module 25 can also be used to: authenticate the data access request and obtain the user's identity information; determine the user's role based on the user's identity information, where the role can be any one of the following: grid dispatcher, photovoltaic owner, and maintenance personnel; wherein, the grid dispatcher role has a first set of permissions, including reading all data, issuing fault control commands, and performing recovery operations; the photovoltaic owner role has a second set of permissions, including reading its own photovoltaic data, receiving fault alarms, and controlling its own photovoltaic output; and the maintenance personnel role has a third set of permissions, including reading equipment status and fault history, uploading inspection reports, and controlling inspection drones; and verify whether the operation requested by the data access request falls within the role's permission set according to the permission policy corresponding to the role.

[0119] In one possible embodiment, the unified protocol adaptation module 22 can also be used to: extend the definition of a dedicated logic node for photovoltaic fault analysis, which includes: a distributed photovoltaic logic node, containing photovoltaic system identification data objects, photovoltaic system operating status data objects, and photovoltaic system health status data objects; a photovoltaic inverter logic node, containing output power measurement data objects, output voltage measurement data objects, output current measurement data objects, output frequency measurement data objects, and power factor measurement data objects; and a photovoltaic power measurement logic node, containing cumulative power generation data objects, available capacity data objects, and ambient temperature measurement data objects; wherein the distributed photovoltaic logic node, photovoltaic inverter logic node, and photovoltaic power measurement logic node each have a unified and standardized data object name and reference path; correspondingly, the distributed photovoltaic logic node, photovoltaic inverter logic node, and photovoltaic power measurement logic node are used to perform a structured description of data with a unified data format to generate photovoltaic data containing data object names and reference paths.

[0120] The interface implementation device for multi-source data fusion of photovoltaic grid-connected distribution networks provided in this application embodiment can execute the technical solution shown in the above-described interface implementation method embodiment for multi-source data fusion of photovoltaic grid-connected distribution networks. Its implementation principle and beneficial effects are similar and will not be repeated here.

[0121] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0122] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0123] It should be noted that the above-described device embodiments are merely illustrative, and the device of this application can be implemented in other ways. Furthermore, it should be understood that the division of the various modules in the above device is only a logical functional division; in actual implementation, they can be fully or partially integrated into a single physical entity, or they can be physically separated. These modules can all be implemented in software via processing element calls; they can all be implemented in hardware; or some modules can be implemented by processing element calls to software, while others are implemented in hardware. For example, the unified protocol adaptation module can be a separately established processing element, or it can be integrated into a chip in the above device. Alternatively, it can be stored as program code in the memory of the above device, and its functions can be called and executed by a processing element of the above device. The implementation of other modules is similar. In addition, these modules can be fully or partially integrated together, or they can be implemented independently. The processing element here can be an integrated circuit with signal processing capabilities. During implementation, each step of the above method or each of the above modules can be completed through integrated logic circuits in the hardware of the processor element or through software instructions.

[0124] For example, these modules can be one or more integrated circuits configured to implement the above methods, such as one or more Application Specific Integrated Circuits (ASICs), one or more Digital Signal Processors (DSPs), or one or more Field Programmable Gate Arrays (FPGAs). As another example, when a module is implemented using processing element scheduler code, the processing element can be a general-purpose processor, such as a Central Processing Unit (CPU) or other processor capable of calling program code. Furthermore, these modules can be integrated together as a System-On-a-Chip (SOC).

[0125] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., Digital Video Discs, DVDs), or semiconductor media (e.g., solid-state disks (SSDs)).

[0126] Figure 3 A schematic diagram of the structure of an electronic device provided as an exemplary embodiment of this application. For example... Figure 3 As shown, the electronic device 30 in this embodiment includes:

[0127] At least one processor 31; and a memory 32 communicatively connected to at least one processor;

[0128] The memory 32 stores instructions that can be executed by at least one processor 31 to cause the electronic device to perform the method as described in any of the above embodiments.

[0129] Alternatively, the memory 32 can be either standalone or integrated with the processor 31.

[0130] The memory 32 may include high-speed random access memory (RAM) and may also include non-volatile memory, such as at least one disk storage device.

[0131] The processor 31 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application. Specifically, when implementing the interface implementation method for multi-source data fusion in photovoltaic grid-connected distribution networks described in the foregoing method embodiments, the electronic device may be, for example, an electronic device with processing capabilities such as a server.

[0132] Optionally, the electronic device may also include a communication interface 33. In specific implementations, if the communication interface 33, memory 32, and processor 31 are implemented independently, they can be interconnected via a bus to complete communication. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc., but this does not imply that there is only one bus or one type of bus.

[0133] Optionally, in a specific implementation, if the communication interface 33, memory 32 and processor 31 are integrated on a single chip, then the communication interface 33, memory 32 and processor 31 can communicate through an internal interface.

[0134] The implementation principle and technical effects of the electronic device provided in this embodiment can be found in the foregoing embodiments, and will not be repeated here.

[0135] This application also provides a computer-readable storage medium storing computer-executable instructions. When the computer-executable instructions are executed, they are used to implement the method steps as described in the above method embodiments. The specific implementation methods and technical effects are similar and will not be repeated here.

[0136] The aforementioned computer-readable storage media can be implemented from any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read Only Memory (PROM), Read Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0137] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Alternatively, the readable storage medium can be an integral part of the processor. The processor and the readable storage medium can reside within an application-specific integrated circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in an interface implementation device for multi-source data fusion in a photovoltaic grid-connected distribution network.

[0138] This application also provides a computer program product, including a computer program, which, when executed, implements the method steps as described in the above method embodiments. The specific implementation and technical effects are similar and will not be repeated here.

[0139] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0140] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0141] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. An interface implementation method for multi-source data fusion in photovoltaic grid-connected distribution networks, characterized in that, include: Obtain the raw data packets uploaded by devices at each end of the photovoltaic grid-connected distribution network; Based on the device identifier, the communication protocol corresponding to the original data packet is identified. According to the identification result, the corresponding protocol adapter is loaded from the preset protocol adapter library. The original data packet is converted into data with a unified data format through the protocol adapter according to the data address mapping table corresponding to the device. Perform multi-layer quality checks on the data with the unified data format, generate quality labels for data that fails the checks, and perform automatic repair. A three-tier caching architecture is used to classify and store data that has undergone quality verification and repair according to real-time requirements. In response to a client's data access request, the client's access permissions are verified according to a preset role access control policy. If the verification is successful, data is extracted from the three-layer caching architecture as needed and pushed to the client according to the push protocol supported by the client.

2. The interface implementation method for multi-source data fusion in photovoltaic grid-connected distribution networks according to claim 1, characterized in that, The step of converting the original data packet into data with a unified data format according to the data address mapping table corresponding to the device includes: The original data packet is parsed to extract the register address and register value; According to the data address mapping table, the register address is mapped to an internally unified data object identifier; Based on the preset unit conversion coefficients in the data address mapping table, the register value is converted into a value in engineering units. According to the preset unified data structure, the data object identifier and the numerical value under the engineering unit are encapsulated into data with a unified data format.

3. The interface implementation method for multi-source data fusion in photovoltaic grid-connected distribution networks according to claim 1, characterized in that, The step of performing multi-level quality checks on the data with a unified data format includes: Perform a range check on the data with the unified data format to verify whether the data value of the data with the unified data format is within a preset physical range; A rate of change check is performed on the data with a uniform data format to verify whether the rate of change between the data value at the current sampling time and the data value at the previous sampling time exceeds a preset maximum allowable rate of change threshold. A consistency check is performed on the data with a unified data format to verify whether the logical relationship between the data value of the data with a unified data format and the data value of the associated data point meets the preset logical constraints. Perform an integrity check on the data with the unified data format to verify whether the data frame structure corresponding to the data with the unified data format is complete and whether any required fields are missing. Based on the verification results, generate corresponding quality labels.

4. The interface implementation method for multi-source data fusion in photovoltaic grid-connected distribution networks according to claim 3, characterized in that, For data that fails quality verification, automatic repair is performed according to a preset repair strategy, including: For data that fails to be checked because the data value exceeds the preset physical range or because the rate of change exceeds the preset maximum allowable rate of change threshold, interpolation is used to generate repair data. For data that fails to be checked due to missing required fields or incomplete data frame structure, a preset time series prediction model is used to generate prediction data to fill in the missing values. For data that fails to be checked due to the logical relationship not meeting the logical constraints, the theoretical value of the related data point as the dependent variable is calculated from the related data point as the independent variable based on the physical law constraint relationship between the related data points involved in the logical constraints, and the corresponding measured value is replaced by the theoretical value to repair it. The repaired data or the predicted data is marked as a predicted value and assigned a quality score lower than the measured value. When communication is detected to have been restored or the data source has been restored to normal, the predicted value is stopped and the measured value is used as the current data. The deviation between the predicted value and the measured value is recorded and fed back to the time series prediction model to update the model parameters.

5. The interface implementation method for multi-source data fusion in photovoltaic grid-connected distribution networks according to any one of claims 1 to 4, characterized in that, The three-tier caching architecture is used to classify and store the data, after quality verification and repair, according to real-time requirements, including: The real-time data acquired at the current sampling time is written to the first cache layer, which uses an in-memory database for use by fault handling applications with the highest latency requirements. The statistical data aggregated at the minute level is written to the second cache layer, which uses a time-series database for use by trend analysis and visualization applications. Data is archived from the second cache layer to the third cache layer and stored as historical data. The third cache layer uses a relational database for use by report generation and deep analysis applications. Data is archived sequentially from the first cache layer to the second cache layer, and from the second cache layer to the third cache layer.

6. The interface implementation method for multi-source data fusion in photovoltaic grid-connected distribution networks according to claim 5, characterized in that, The push protocol includes at least one of WebSocket protocol, Message Queuing Telemetry Transport Protocol (MQTT), and Hypertext Transfer Protocol (HTTP); the on-demand extraction of data from the three-layer caching architecture and push to the client includes: The topic identifier and filtering conditions carried in the data access request are parsed, the corresponding data topic is matched from the preset topic list according to the topic identifier, and the corresponding data is extracted from the three-layer cache architecture according to the data topic; The extracted data is filtered according to the filtering conditions. A data distribution channel is established based on the client's subscription information. The filtered data is encapsulated according to the push protocol supported by the client and sent to the client through the data distribution channel at a set push interval.

7. The interface implementation method for multi-source data fusion in photovoltaic grid-connected distribution networks according to claim 6, characterized in that, The step of verifying the client's access permissions according to a preset role-based access control policy includes: The data access request is authenticated to obtain the user identity information of the client; The user's role is determined based on the user's identity information. The role can be any one of the following: grid dispatcher, photovoltaic owner, or maintenance personnel. The grid dispatcher role has a first set of permissions: reading all data, issuing fault control commands, and performing recovery operations. The photovoltaic owner role has a second set of permissions: reading data of its own photovoltaic system, receiving fault alarms, and controlling its own photovoltaic output. The maintenance personnel role has a third set of permissions: reading equipment status and fault history, uploading inspection reports, and controlling inspection drones. Based on the permission policy corresponding to the role, verify whether the operation requested by the data access request belongs to the permission set of the role.

8. The interface implementation method for multi-source data fusion in photovoltaic grid-connected distribution networks according to any one of claims 1 to 4, characterized in that, Also includes: The definition of a dedicated logic node for photovoltaic fault analysis is extended, and the dedicated logic node for photovoltaic fault analysis includes: Distributed photovoltaic logical nodes include photovoltaic system identification data objects, photovoltaic system operation status data objects, and photovoltaic system health status data objects; A photovoltaic inverter logic node includes output power measurement data objects, output voltage measurement data objects, output current measurement data objects, output frequency measurement data objects, and power factor measurement data objects. The photovoltaic power measurement logic node includes a cumulative power generation data object, an available capacity data object, and an ambient temperature measurement data object. Among them, the distributed photovoltaic logic node, the photovoltaic inverter logic node, and the photovoltaic power measurement logic node each have a unified and standardized data object name and reference path; Correspondingly, the distributed photovoltaic logic node, the photovoltaic inverter logic node, and the photovoltaic power measurement logic node are used to perform a structured description of the data with a unified data format, generating photovoltaic data containing the data object name and the reference path.

9. An interface implementation device for multi-source data fusion in photovoltaic grid-connected distribution networks, characterized in that, include: The acquisition module is used to acquire the raw data packets uploaded by devices at each end of the photovoltaic grid-connected distribution network; The unified protocol adaptation module is used to identify the communication protocol corresponding to the original data packet based on the device identifier, load the corresponding protocol adapter from the preset protocol adapter library according to the identification result, and convert the original data packet into data with a unified data format through the protocol adapter according to the data address mapping table corresponding to the device. The data quality control module is used to perform multi-level quality checks on the data with a unified data format, generate quality labels for data that fails the checks, and perform automatic repair. The tiered caching module is used to classify and store data that has undergone quality verification and repair according to real-time requirements using a three-tiered caching architecture. The data push module is used to respond to the client's data access request, verify the client's access permissions according to the preset role access control policy, and after the verification is successful, extract data from the three-layer caching architecture as needed and push it to the client according to the push protocol supported by the client.

10. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory is used to store computer-executed instructions; The processor is configured to execute the computer execution instructions to implement the method as described in any one of claims 1 to 8.

Images