New energy equipment operation and maintenance method and system

Abstract

The invention relates to the technical field of equipment operation and maintenance, and discloses a new energy equipment operation and maintenance method and system, and the method comprises the steps: receiving a first equipment information set, a first protocol plug-in and a first point table configuration information set uploaded by a user side; based on the first equipment information set, performing configuration processing on the first protocol plug-in and the first point table configuration information set to obtain a second equipment information set and a target point table configuration information set; based on the second equipment information set, the target point table configuration information set and a preset non-blocking scheduling and exponential backoff retry strategy, original equipment data sets of the multiple target new energy equipment are collected through threads; performing standardization processing on the original equipment data set to obtain a target equipment data set; and the target equipment data set is sent to the client, so that the client manages the operation and maintenance process of the multiple target new energy equipment based on the target equipment data set, fusion of heterogeneous equipment data is realized, and the operation and maintenance management difficulty of field equipment is reduced.

Description

Technical Field

[0001] This invention relates to the field of equipment operation and maintenance technology, specifically to a method and system for the operation and maintenance of new energy equipment. Background Technology

[0002] With the rapid development of the new energy industry, especially wind power and photovoltaic applications, the types of field equipment are becoming increasingly diverse, and communication protocols are exhibiting highly heterogeneous characteristics. Common protocols coexist widely due to differences between manufacturers and site locations, lacking a unified access standard, which increases the complexity of system integration and operation and maintenance. Equipment data lacks standardization in terms of structure, naming, units, and precision, making it difficult to uniformly parse and integrate data, affecting its usability and consistency, and consequently leading to difficulties in field equipment operation and maintenance management.

[0003] With the rapid development of the new energy industry, especially wind power and photovoltaic applications, the types of field equipment are becoming increasingly complex, and communication protocols are exhibiting significant heterogeneity. Common protocols used by different manufacturers and sites coexist widely, but a unified access standard is lacking, which undoubtedly increases the complexity of system integration and operation and maintenance. The lack of standardization in equipment data structure, naming, units, and precision makes it difficult to achieve unified data parsing and fusion, thus adversely affecting its usability and consistency, and consequently leading to difficulties in field equipment operation and maintenance management. Summary of the Invention

[0004] This invention provides a method and system for the operation and maintenance of new energy equipment, in order to solve the problem that the difficulty in achieving unified parsing and fusion of data has an adverse effect on its availability and consistency, thus leading to difficulties in on-site equipment operation and maintenance management.

[0005] In a first aspect, the present invention provides a method for the operation and maintenance of new energy equipment, used in a new energy equipment operation and maintenance system, wherein the new energy equipment operation and maintenance system is connected to a user terminal and a client terminal respectively; the method includes: The system receives a first set of device information, a first set of protocol plugins, and a first set of point table configuration information uploaded by the user. Based on the first set of device information, it performs configuration processing on the first set of protocol plugins and the first set of point table configuration information to obtain a second set of device information and a target point table configuration information set. Based on the second set of device information, the target point table configuration information set, and a preset non-blocking scheduling and exponential backoff retry strategy, it uses threads to collect raw device datasets from multiple target new energy devices, all of which are in an enabled state. It performs standardization processing on the raw device datasets to obtain target device datasets. The target device datasets are then sent to the client so that the client can manage the operation and maintenance process of multiple target new energy devices based on the target device datasets and obtain device operation and maintenance results.

[0006] The new energy equipment operation and maintenance method provided by this invention breaks down the information fragmentation caused by differences between manufacturers and sites by centrally receiving multi-dimensional configuration information, avoiding management chaos caused by scattered storage of configuration information, and improving configuration entry efficiency. Furthermore, configuration processing establishes the association between devices, protocols, and point tables, forming a standardized configuration system, thereby reducing docking failures caused by configuration mismatches. Furthermore, preset non-blocking scheduling avoids task blocking, and combined with exponential backoff retries, it automatically recovers from temporary data collection failures. Furthermore, it ensures efficient data collection from target devices in the enabled state, reduces manual intervention, and improves the real-time performance and stability of data collection, thus supporting the high-frequency data requirements of new energy equipment. Furthermore, standardization eliminates heterogeneous data differences, improves data consistency and availability, provides a foundation for cross-device and cross-scenario data fusion, and helps meet the data governance needs of new energy enterprises. Furthermore, through the target device dataset, the client can achieve precise operation and maintenance management, helping to improve the accuracy of operation and maintenance decisions.

[0007] In one optional implementation, based on the first device information set, the first protocol plugin and the first point table configuration information set are configured to obtain the second device information set and the target point table configuration information set, including: The first device information set and the first point table configuration information set are verified separately to obtain the verified third device information set and the second point table configuration information set; the first protocol plugin is parsed to obtain the plugin metadata set; based on the plugin metadata set, the first protocol plugin is verified for signature and version compatibility; when the verification is successful, the first protocol plugin is loaded using an independent class loader and bound to the third device information set to obtain the second device information set; the second point table configuration information set is bound to the first protocol plugin and the second device information set to obtain the target point table configuration information set.

[0008] The new energy equipment operation and maintenance method provided by this invention, by verifying the first equipment information set and the first point table configuration information set, can filter out configurations with incorrect formats and logical conflicts from the source, helping to reduce the occupation of system resources by invalid configurations, lower the probability of failure in the data collection process, and improve configuration reliability. Furthermore, by parsing plugins and extracting plugin metadata, standardized management of plugin information is achieved, helping to avoid loading failures due to missing plugin information and improving plugin management efficiency. Furthermore, by performing signature verification and version compatibility verification on protocol plugins, tampering with plugins can be prevented and low-version systems cannot load high-version plugins, ensuring plugin loading security, reducing the risk of system crashes due to plugin issues, and improving system stability. Furthermore, by using an independent class loader to load protocol plugins, class isolation between plugins is achieved, preventing plugin conflicts from affecting the data collection of other devices and improving the system's adaptability to heterogeneous protocols. At the same time, a unique association between devices and protocols is established through binding operations. Furthermore, binding point table configuration information to protocol plugins and device information respectively ensures that point table fields are compatible with protocol types, helping to improve data parsing accuracy and avoiding data extraction failures due to incorrect point table configurations.

[0009] In one optional implementation, based on a second device information set, a target point table configuration information set, and a preset non-blocking scheduling and exponential backoff retry strategy, threads are used to collect raw device datasets from multiple target new energy devices, including: Based on the second device information set, a fourth device information set for multiple target new energy devices is obtained; based on the fourth device information set, multiple acquisition tasks for multiple target new energy devices are generated; based on a preset non-blocking scheduling and exponential backoff retry strategy, multiple acquisition tasks are executed using threads to obtain multiple raw data frames for multiple target new energy devices; the multiple raw data frames are parsed and processed, and based on the target point table configuration information set, the parsed multiple raw data frames are extracted to obtain multiple target data frames; the multiple target data frames are encapsulated to obtain the original device dataset.

[0010] The new energy equipment operation and maintenance method provided by this invention, by selecting target devices in an active state from the configured equipment and extracting key communication and related information, ensures that data collection tasks are only for valid devices, reducing invalid collection requests and improving the utilization rate of collection resources. Furthermore, by setting collection tasks for each target new energy device, standardized management of collection tasks is achieved, facilitating task scheduling, modification, and monitoring, and improving task management efficiency. Furthermore, by using preset non-blocking scheduling, task blocking can be avoided. Simultaneously, combined with exponential backoff retries, temporary collection failures can be automatically recovered, improving the efficiency of concurrent collection by multiple devices, reducing the loss of raw data due to temporary failures, and ensuring the continuity of data collection. Furthermore, by parsing and processing and extracting data in conjunction with point table configuration information, the transformation of raw data into structured data is achieved, improving data parsing efficiency. Furthermore, by encapsulation processing, complete raw materials are provided for standardized data processing, improving data flow efficiency.

[0011] In one optional implementation, the original device dataset is standardized to obtain the target device dataset, including: Using a predefined domain standard data model, the original device dataset is mapped to obtain the first device dataset; the first device dataset is then converted and normalized to obtain the second device dataset; the second device dataset is then mapped with enumerated values ​​and normalized semantically to obtain the third device dataset; and the third device dataset is then evaluated for quality and invalid values ​​are removed to obtain the target device dataset.

[0012] The new energy equipment operation and maintenance method provided by this invention maps the original equipment dataset to standard fields through a pre-set domain standard data model, achieving semantic uniformity of fields and improving data fusion capabilities. Furthermore, through unit conversion and dimension normalization, it achieves data dimension consistency and supports direct comparison and calculation of data from different devices, improving data usability. Further, through enumerated value mapping and semantic normalization, it improves data readability, reduces the understanding cost for operation and maintenance personnel, eliminates the need to memorize manufacturer coding rules, and improves operation and maintenance efficiency. Finally, through quality assessment and invalid value handling, it improves data credibility, prevents invalid data from flowing into the operation and maintenance system, thereby helping to reduce decision-making bias and support precise operation and maintenance.

[0013] In one alternative implementation, the method further includes: When the user client uploads the second protocol plugin and the hot deployment update instruction, the second protocol plugin is loaded. The second protocol plugin and the first protocol plugin are different plugins of the same protocol. When the second protocol plugin is loaded, the new energy device corresponding to the first protocol plugin is updated in a gray-scale manner, and the collection status of the updated new energy device is obtained. When the collection status of the updated new energy device is not abnormal, the first protocol plugin is updated using the second protocol plugin.

[0014] The new energy equipment operation and maintenance method provided by this invention enables uninterrupted system loading of plug-ins through hot deployment, ensuring continuous data collection, meeting the uninterrupted operation requirements of new energy equipment, and reducing data loss caused by system restarts. Furthermore, canary updates reduce the risk of plug-in updates, thereby controlling the impact of failures to a small scope and helping to avoid operational crises caused by full-scale failures. Moreover, determining full updates based on canary verification results ensures the stability of plug-in updates, maintaining a high success rate of equipment data collection after a full update, and improving the security of system iteration.

[0015] In an optional implementation, the method further includes: upon receiving a modification instruction uploaded by a user terminal, modifying the first device information set based on the modification instruction.

[0016] The new energy equipment operation and maintenance method provided by this invention modifies the first equipment information set based on the modification instructions uploaded by the user terminal. It can respond to modification needs in real time without restarting the system, which helps to improve the efficiency of configuration adjustment, reduce the data collection interruption time caused by information changes, and thus support flexible management of the entire life cycle of the equipment.

[0017] In an optional implementation, the method further includes: constructing a visual acquisition link for multiple target new energy devices using a graphical configuration interface, so that the client can locate the faults of multiple target new energy devices based on the visual acquisition link.

[0018] The new energy equipment operation and maintenance method provided by this invention can graphically display the data flow by constructing a visual acquisition link, thereby intuitively presenting abnormal nodes, which helps to shorten the fault location time, improve operation and maintenance efficiency, and reduce equipment downtime losses.

[0019] In an optional implementation, the method further includes: monitoring the operation of each link component in the visualization acquisition link and acquiring multiple real-time operation status information; and updating the visualization acquisition link based on the multiple real-time operation status information.

[0020] The new energy equipment operation and maintenance method provided by this invention achieves link status awareness through real-time collection of component status, thereby enabling early identification of potential faults and preventing fault escalation. Furthermore, updating the visualized collection link based on real-time operating status information ensures that operation and maintenance personnel can monitor the link health status in real time, improving fault response speed and supporting proactive operation and maintenance.

[0021] In an optional implementation, the method further includes: storing the target device dataset in a local cache when an abnormal situation occurs, including network connection failure, data forwarding failure, platform response latency exceeding a threshold, and offline mode.

[0022] The new energy equipment operation and maintenance method provided by this invention ensures data integrity by storing key data locally as a backup. This allows for the retransmission of cached data after network recovery, avoiding data gaps in remote sites and poor signal scenarios, and meeting the requirement of the new energy industry that data must not be lost.

[0023] Secondly, the present invention provides a new energy equipment operation and maintenance system, which is connected to a user terminal and a client terminal respectively, for executing the new energy equipment operation and maintenance method of the first aspect or any corresponding embodiment described above; the system includes an access module, a data acquisition and parsing module, a data standardization module and a storage and forwarding module.

[0024] The new energy equipment operation and maintenance system provided by this invention achieves full-process coverage of configuration, data collection, standardization, and forwarding through an integrated modular design, reducing the complexity of system deployment and maintenance. At the same time, the collaborative work between modules ensures the implementation of new energy equipment operation and maintenance methods, thereby helping to support the data needs of the entire new energy equipment operation and maintenance process. Attached Figure Description

[0025] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0026] Figure 1 This is a structural block diagram of a new energy equipment operation and maintenance system according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating the operation and maintenance method for new energy equipment according to an embodiment of the present invention; Figure 3 This is a schematic diagram of the overall architecture of a multi-protocol data acquisition, storage, and forwarding method for data standardization and link visualization according to an embodiment of the present invention. Detailed Implementation

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

[0028] It is understood that before using the technical solutions disclosed in the various embodiments of the present invention, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in the present invention and their authorization should be obtained in accordance with relevant laws and regulations through appropriate means.

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

[0030] As an optional application scenario of this invention, such as Figure 1 As shown, a new energy equipment operation and maintenance system 1 is provided, which is connected to a user terminal 2 and a client terminal 3 respectively. The new energy equipment operation and maintenance system 1 includes: an access module 10, a data acquisition and parsing module 20, a data standardization module 30 and a storage and forwarding module 40.

[0031] With the rapid development of the new energy industry, especially wind and solar power, the types of field equipment are becoming increasingly diverse, and communication protocols are exhibiting highly heterogeneous characteristics. Common protocols coexist widely due to differences between manufacturers and sites, lacking a unified access standard, which increases the complexity of system integration and operation and maintenance. Equipment data lacks standardization in terms of structure, naming, units, and precision, making it difficult to uniformly parse and integrate data, affecting its usability and consistency. Traditional data acquisition links are mostly in a "black box" mode, lacking link status visualization and real-time monitoring, making it difficult to detect and locate faults in a timely manner, severely restricting the stable operation of the system and the assurance of data quality. There is a need to invent a standardized data acquisition and link visualization integration method for heterogeneous protocol devices to support the data governance and intelligent transformation needs of new energy enterprises.

[0032] According to an embodiment of the present invention, a method for operation and maintenance of new energy equipment is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0033] This embodiment provides a method for the operation and maintenance of new energy equipment, which can be used in the aforementioned new energy equipment operation and maintenance system 1. Figure 2 This is a flowchart of a new energy equipment operation and maintenance method according to an embodiment of the present invention, such as... Figure 2 As shown, the process includes the following steps: Step S201: Receive the first device information set, the first protocol plugin, and the first point table configuration information set uploaded by the user terminal.

[0034] In an optional embodiment, the first device information set represents a structured data set uploaded by the user terminal 2 that describes the basic attributes and communication parameters of the new energy equipment. It serves as the identity and communication credentials for the new energy equipment to access the new energy equipment operation and maintenance system 1, and may contain key information for the full lifecycle management of the equipment and protocol integration.

[0035] For example, the data structure of the first device information set is as follows: {"deviceId":"WTG001","deviceName":"Wind Turbine 1#","deviceType":"Wind Turbine Generator Set","vendor":"Goldwind","location":"Site A-1","protocolType":"Modbus","ipAddress": "192.168.10.101", "port":502,"enabled": true}.

[0036] Among them, deviceId represents the unique identifier of the device; deviceName represents the device name; deviceType represents the device type, which supports custom categories and is used to match the corresponding standard data model; vendor represents the device manufacturer and is used to associate with the manufacturer's exclusive point table template; location represents the device installation location and is used to support site-level operation and maintenance management; protocolType represents the communication protocol type supported by the device and is used to bind the corresponding protocol plugin later; Modbus represents a serial communication protocol; ipAddress / port represents communication parameters, which are automatically adapted according to the protocol type; enabled represents the device's enabled status (true / false).

[0037] In an optional embodiment, the first protocol plugin refers to an independent software component uploaded by the user terminal 2 for implementing data interaction using a specific communication protocol. It acts as a translator for establishing communication between the new energy equipment operation and maintenance system 1 and the new energy equipment. Furthermore, this first protocol plugin needs to conform to the system plugin interface specification to ensure compatibility.

[0038] For example, the framework of the first protocol plugin is as follows: (1) Interface implementation: It must include a ProtocolAdapter interface implementation class, providing three core methods: getProtocolType() (get protocol type), validateConnection() (validate device connection), and readPoints() (read device data points); (2) Meta information: stored in the META-INF directory of the Jar package, including name (plugin name, such as Modbus-Adapter), version (version, such as v1.2), sha256 (hash signature, used to verify integrity), minCoreVersion (minimum system core version, such as v1.8), and capabilities (supported capabilities, such as support for register address resolution). (3) Dependency libraries: open source libraries required for encapsulating protocol communication (such as the Modbus plugin containing the Modbus4J library and the MQTT plugin containing the Eclipse Paho library), which do not require additional system deployment.

[0039] (4) Data format: Java JAR package. Furthermore, built-in plugins are pre-stored in the plugin repository; user-defined plugins must be uploaded manually.

[0040] In an optional embodiment, the first point table configuration information set represents the structured data set uploaded by the user terminal 2, which is used to define the data collection dimensions and parsing rules of the device, and is a mapping dictionary from which the system extracts effective information from the original data of the device.

[0041] For example, the data structure of the first point table configuration information set is as follows: {"pointName":"Power Generation","registerAddress":30001,"functionCode":3,"dataType":"FLOAT32","scale":0.01,"unit":"kW","standardField":"active_power","precision":2}.

[0042] Among them, ointName represents the data point name; registerAddress represents the register address, which is only applicable to register-based protocols such as Modbus and is used to identify the storage location of data in the device; functionCode represents the function code, which is used to specify the protocol operation type; dataType represents the data type, which is used to define the parsing format of the raw data; scale represents the scaling factor, which is used to calibrate the raw data; unit represents the raw unit, which is used for subsequent unit conversion and dimension normalization; standardField represents the standard field mapping, which is used to associate with the system's preset domain standard data model fields; precision represents the precision, which is used to define the number of decimal places to retain in the data.

[0043] In an optional embodiment, the user can initiate the upload operation of three types of configuration information through the user terminal 2 and by utilizing the Web configuration interface or open API of the new energy equipment operation and maintenance system 1.

[0044] For example, after a user logs into the new energy equipment operation and maintenance system 1 through user terminal 2, they enter the "Equipment Management → Equipment Registration" module and select "Add Equipment". Then, they fill in the fields of the first equipment information set in the form.

[0045] Furthermore, if the device requires a custom protocol, click "Protocol Plugin Upload" and select the first locally stored protocol plugin JAR file. Simultaneously, click "Point Table Configuration → Add Point Table" to manually enter or select a template to generate the first point table configuration information set. Finally, click "Submit" and encapsulate the three types of configuration information into JSON format.

[0046] Furthermore, through the above operations, users can upload the first device information set, the first protocol plugin, and the first point table configuration information set to the new energy equipment operation and maintenance system 1.

[0047] In an optional embodiment, the user can also simultaneously upload a first device information set, a first protocol plugin, and a first point table configuration information set of multiple devices through the user terminal 2.

[0048] In one optional embodiment, the user first logs into the system configuration interface, finds and selects the device registration module. For data entry, there are two options: single-device entry and multi-device batch import. For single-device entry, the user needs to fill in fields such as device ID, device name, device type, manufacturer, location, protocol type, IP address, and port. For multi-device batch import, the user uploads a CSV / Excel file containing the above fields and then clicks the batch import button. Furthermore, the entered or imported information can form a corresponding first device information set.

[0049] In one optional embodiment, the user enters the system point table configuration module and can choose to enter point table information in two ways: template-based configuration or custom configuration.

[0050] When configuring based on a template, the user selects the manufacturer and model of the device, and the new energy equipment operation and maintenance system 1 retrieves the corresponding standard template from the point table template library. The user can modify some fields according to actual needs. When configuring custom data, the user needs to manually fill in the field information for each data point, which may include pointName, registerAddress, functionCode, dataType, scale, unit, standardField, precision, etc.

[0051] Furthermore, users can also import point table configurations in batches via Excel or JSON files. The new energy equipment operation and maintenance system 1 can then automatically parse the field information in the file to generate a draft of the point table configuration, which users can then fine-tune.

[0052] Step S202: Based on the first device information set, configure the first protocol plugin and the first point table configuration information set to obtain the second device information set and the target point table configuration information set.

[0053] In one optional embodiment, the second device information set represents a standardized device information set that includes the association between devices and protocols, formed after the first device information set has been verified, loaded, and bound by the protocol plugin.

[0054] In one optional embodiment, the target point table configuration information set represents a structured point table set that is formed based on the first point table configuration information set, after logical validity verification and binding with the device / protocol, and can be directly used for data parsing. It is the final mapping rule for the system to extract valid information from the original data of the device.

[0055] In one optional embodiment, using the first device information set as the reference anchor point, the first protocol plugin is subjected to security and compatibility verification and loaded and bound. Then, the first point table configuration information set is subjected to logical legality verification and associated with the device / protocol. Finally, a standardized configuration that can be directly used for data collection, namely the second device information set and the target point table configuration information set, can be output.

[0056] Furthermore, through configuration processing, the dispersed device identities, communication components, and collection rules can be integrated into a collaborative configuration system, which helps to ensure that during subsequent data collection, the new energy equipment operation and maintenance system 1 can accurately identify which device needs to use a certain protocol plugin and collect data according to a certain point table rule.

[0057] Step S203: Based on the second device information set, the target point table configuration information set, and the preset non-blocking scheduling and exponential backoff retry strategy, the original device dataset of multiple target new energy devices is collected using threads.

[0058] Among them, many of the target new energy devices are in operation.

[0059] In an optional embodiment, the preset non-blocking scheduling and exponential backoff retry strategy represents the task scheduling and fault tolerance mechanism pre-configured by the new energy equipment operation and maintenance system 1 to ensure the efficiency of concurrent data acquisition and fault recovery capability of multiple devices: (1) Preset non-blocking scheduling: Based on thread pool grouping management and task isolation logic, independent thread pools are allocated for different types of new energy devices to avoid single device acquisition timeout occupying thread resources and causing other devices' acquisition tasks to be blocked. During the scheduling process, the thread is only responsible for triggering the acquisition request and does not wait for the blocking response. The acquisition result is obtained through the callback mechanism to ensure efficient reuse of thread resources and support multi-device concurrent acquisition with second-level accuracy.

[0060] (2) Pre-configured exponential backoff retry: For temporary faults that occur during the data acquisition process, an exponentially increasing rule for the number of retries and the retry interval is pre-configured. Furthermore, when a data acquisition task of a device fails for the first time, the system automatically adds the task to the retry queue and reschedules it according to the exponential backoff rule, avoiding high-frequency retries from putting additional pressure on the device and network, while maximizing the recovery success rate of temporary faults.

[0061] In one optional embodiment, the raw device dataset represents a structured collection containing raw monitoring data of the target new energy equipment, generated by the system after being collected and parsed by a thread.

[0062] In one optional embodiment, based on the collectable standardized configuration, namely the second device information set and the target point table configuration information set, efficient concurrent acquisition of multiple target new energy devices can be achieved through preset non-blocking scheduling. At the same time, temporary acquisition failures can be handled through exponential backoff retries, thereby ultimately outputting a structured raw device dataset.

[0063] Step S204: Standardize the original device dataset to obtain the target device dataset.

[0064] In one optional embodiment, by standardizing the raw device dataset, raw data from different brands and communication protocols can be converted into a format that conforms to the system's unified standard, thereby forming the corresponding target device dataset.

[0065] Step S205: The target device dataset is sent to the client so that the client can manage the operation and maintenance process of multiple target new energy devices based on the target device dataset and obtain the device operation and maintenance results.

[0066] In one optional embodiment, after the obtained target device dataset is sent to the client 3, the client 3 can carry out operation and maintenance management operations such as real-time monitoring, fault warning, and energy efficiency analysis of multiple target new energy devices based on the target device dataset, and finally generate equipment operation and maintenance results that reflect the health status and operation and maintenance effect of the devices.

[0067] In one optional embodiment, the new energy equipment operation and maintenance system 1 supports forwarding a single piece of data to multiple target systems or multiple clients simultaneously, and the supported methods include MQTT Broker, HTTP / RESTful interface, database and file.

[0068] Furthermore, considering the response capabilities and connectivity status of different targets, the new energy equipment operation and maintenance system 1 has a built-in forwarding scheduler that supports the strategies shown in Table 1 below: Table 1. Intelligent Forwarding and Scheduling Strategies

[0069] The new energy equipment operation and maintenance method provided in this embodiment breaks down the information fragmentation caused by differences between manufacturers and sites by centrally receiving multi-dimensional configuration information, avoiding management chaos caused by scattered storage of configuration information, and improving configuration entry efficiency. Furthermore, configuration processing can establish the association between devices, protocols, and point tables and form a standardized configuration system, thereby reducing docking failures caused by configuration mismatches. Furthermore, preset non-blocking scheduling avoids task blocking, and combined with exponential backoff retries, it can automatically recover from temporary data collection failures. Furthermore, it ensures efficient data collection from target devices in the enabled state, reduces manual intervention, and improves the real-time performance and stability of data collection, thus supporting the high-frequency data requirements of new energy equipment. Furthermore, standardization processing eliminates heterogeneous data differences, improves data consistency and availability, provides a foundation for cross-device and cross-scenario data fusion, and helps meet the data governance needs of new energy enterprises. Furthermore, through the target device dataset, the client can achieve precise operation and maintenance management, which helps improve the accuracy of operation and maintenance decisions.

[0070] In some optional implementations, step S202 above includes: Step S2021: Verify the first device information set and the first point table configuration information set respectively to obtain the third device information set and the second point table configuration information set that pass the verification.

[0071] In one optional embodiment, by performing multi-dimensional compliance checks on the first device information set and the first point table configuration information set, invalid configurations with format errors and logical conflicts are filtered out, and a third device information set and a second point table configuration information set that have passed the checks can be output, thus ensuring the configuration quality from the source.

[0072] In one optional embodiment, after receiving the first set of device information, the new energy equipment operation and maintenance system 1 first converts the device information into JSON format via a web interface or API and submits it to the backend service. Next, it performs format validation, checking whether the fields are complete, such as ensuring that required fields like deviceId and protocolType are not empty, and whether the format is valid, such as requiring IP addresses to conform to IPv4 standards and ports to be integers between 1 and 65535.

[0073] Furthermore, a duplicate verification is performed by querying the centralized configuration center to check if the deviceId already exists. If it does, a message is displayed indicating that the device ID already exists and requesting re-entry to avoid duplicate registration. After all verifications pass, device information can be categorized and stored according to device type, and simultaneously synchronized to the configuration center cache for faster subsequent retrieval.

[0074] In one optional embodiment, after receiving the first point table configuration information set, the new energy equipment operation and maintenance system 1 automatically starts the point table configuration verification engine to perform multi-dimensional verification and obtains the second point table configuration information set that has passed the verification.

[0075] Specifically, first, the uniqueness of the address is verified by checking if there are duplicate registerAddresses in the point table for the same device. If so, a message indicating duplicate register addresses is displayed, and the user is asked to modify them. Second, the validity of the function code is verified by checking if the functionCode conforms to the specifications of the corresponding protocol. If it is invalid, a message indicating an invalid function code is displayed, and the user is asked to confirm. Third, the data type matching is verified to ensure that the dataType matches the actual data type of the field, avoiding data parsing errors. Finally, the completeness of the fields is verified by checking if required fields are empty. If any are missing, a message indicating that required fields cannot be empty is displayed, and the user is asked to supplement them.

[0076] In one optional embodiment, users can also edit, delete, and manage versions of the point table configuration. During editing, users can modify non-critical fields such as multiplier, unit, and precision. If critical fields such as registerAddress and functionCode need to be modified, the system will re-trigger the verification process to ensure the modified configuration is valid.

[0077] Furthermore, when deleting a point table configuration, the system first checks whether the point table is associated with a data acquisition task. If it is, the system prompts that the point table is associated with a data acquisition task and the task must be stopped before deletion to avoid affecting the data acquisition work.

[0078] In one optional embodiment, after each modification of the point table configuration, the system can also automatically generate a new version number and retain historical version records, allowing users to roll back to historical versions at any time for easy tracking of configuration changes.

[0079] Step S2022: Parse the first protocol plugin to obtain the plugin metadata set.

[0080] In an optional embodiment, the plugin metadata set represents the core description information set extracted after parsing the first protocol plugin (in the form of a Jar package). It may include basic identification information such as name (plugin name), version (plugin version), sha256 (plugin hash signature), compatibility information such as minCoreVersion (minimum system core version required by the plugin), functional capability information such as capabilities[] (core capabilities supported by the plugin), and interface association information such as the path of the ProtocolAdapter interface implementation class.

[0081] In an optional embodiment, the new energy equipment operation and maintenance system 1 can decompress the first protocol plugin Jar package to a temporary directory and read the preset metadata file, i.e., the plugin metadata set, under the META-INF directory within the Jar package.

[0082] Step S2023: Based on the plugin metadata set, perform signature verification and version compatibility verification on the first protocol plugin.

[0083] In one optional embodiment, the complete binary content of the first protocol plugin Jar package can be subjected to SHA256 hash calculation to obtain the actual hash value. Then, the actual hash value is compared bit by bit with the sha256 field in the plugin metadata set.

[0084] Furthermore, if the two are completely consistent, it means that the plugin has not been tampered with, i.e., there is no malicious modification or file corruption, and the signature verification passes; if they are inconsistent, it is determined that the plugin integrity verification fails, the plugin is refused to be loaded, and feedback is given to the user.

[0085] Furthermore, the system can read the current system's core version and extract `minCoreVersion` from the plugin metadata set. Then, the two versions are compared. If the system version is lower than `minCoreVersion`, a message is displayed indicating that the plugin version is too high and the system core needs to be upgraded. Simultaneously, format validation is performed, checking whether the JAR file conforms to the Java standard format and whether it contains a ProtocolAdapter interface implementation class. If this implementation class is missing, a message is displayed indicating that the plugin does not conform to the specification and lacks a ProtocolAdapter interface implementation.

[0086] Furthermore, once all verifications pass, the system stores the JAR file in the plugin's temporary directory, awaiting the loading instruction.

[0087] Step S2024: When the verification is successful, the first protocol plugin is loaded using the independent class loader, and the first protocol plugin is bound to the third device information set to obtain the second device information set.

[0088] In one optional embodiment, the independent class loader refers to the URLClassLoader class loader that the system allocates separately for each protocol plugin. It is a core technical component for achieving class isolation between plugins, which can avoid conflicts between classes with the same name between different plugins; it can ensure that the dependency library of each plugin is only effective within its own class loader scope, without affecting the system's core class library and other plugins; it can support independent loading and unloading of plugins, and close the corresponding class loader when unloading to release resources and avoid memory leaks.

[0089] In one optional embodiment, there are two ways to trigger plugin loading: one is to automatically load the built-in plugin when the system starts, and the other is for the user to select to load the plugin in the configuration interface and specify the name and version of the plugin to be loaded.

[0090] Specifically, when the system loads a plugin, it first assigns an independent URLClassLoader to the plugin to be loaded. This class loader is isolated from the class loaders of other plugins to avoid the situation where different plugins have the same name and the class is overridden. Then, the class loader scans for implementation classes of the ProtocolAdapter interface in the Jar package and instantiates the class.

[0091] Furthermore, the `getProtocolType()` method of the implementation class is called to obtain the protocol type, and the plugin instance is registered with the PluginManager, along with its metadata. Then, the plugin instance is dynamically registered as a Spring Bean using BeanDefinitionRegistry, and the orderly start and stop of the plugin is controlled by the SmartLifecycle interface, initializing the connection pool upon startup and releasing resources upon shutdown.

[0092] Finally, the loading status is fed back to the user. If the loading is successful, the system interface will display a message indicating that the plugin has been successfully loaded. If the loading fails, detailed logs will be output for troubleshooting.

[0093] In an optional embodiment, when there are multiple versions of plugins of the same protocol type and the user triggers loading, the system can store the plugin instance according to the protocol type-version as a unique identifier to avoid repeated loading of plugins of the same protocol and version.

[0094] In one optional embodiment, the latest version of the plugin is recommended by default in the version priority setting, but users can also manually specify a version as the default version. At the same time, independent ClassLoaders are assigned to different versions of the plugin, so that even if classes with the same name exist, they will not interfere with each other, ensuring that multiple versions of plugins can coexist stably.

[0095] In one optional embodiment, the protocolType in the third device information set is read and compared with the protocol type returned by the plugin instance through the getProtocolType() method. If the two are consistent, it ensures that the bound plugin is compatible with the device protocol.

[0096] Furthermore, based on the third device information set, additional specified plugin association fields can be added, such as pluginId (unique plugin identifier), pluginVersion (plugin version), classLoaderId (independent class loader identifier), and pluginConnStatus (plugin connection status with the device), to form a second device information set.

[0097] Step S2025: Bind the second point table configuration information set with the first protocol plugin and the second device information set to obtain the target point table configuration information set.

[0098] In one optional embodiment, the user selects a target device from the device list and enters the device's protocol configuration page. The system then displays the supported protocol types and corresponding available plugin versions based on the device's `protocolType` field. After selecting the target plugin version, the user clicks the "Bind" button.

[0099] Furthermore, upon receiving a binding request, the system first creates a device-plugin association record in the database. This record can contain information such as deviceId, pluginName, pluginVersion, and binding time (bindTime). Then, the binding relationship is synchronized to the centralized configuration center cache to ensure that the data collection and scheduling module can obtain this information in real time.

[0100] In addition, the system can perform connection pre-verification by calling the plugin's `validateConnection()` method and passing in the device's communication parameters to verify the feasibility of the connection between the device and the plugin. If the verification fails, a message will be displayed indicating that the device connection has failed and requesting that the communication parameters be checked. However, users are allowed to force binding for subsequent troubleshooting. Only one protocol plugin can be bound to the same device at a time. If a protocol switch is required, the current plugin must be unbound first to avoid data collection task conflicts.

[0101] In one optional embodiment, the point table field structure can be automatically adjusted according to the type of the first protocol plugin. Then, the associated fields and the adapted point table rules are integrated to form a target point table configuration information set.

[0102] In an optional embodiment, if a user needs to unbind a plugin, they can select a device with a bound plugin and click the unbind button. When processing the unbinding operation, the system first stops the data collection task based on the current plugin for that device (if it exists), then deletes the device-plugin connection record, synchronously updates the configuration center cache, and finally calls the plugin's stop method to release the network connection and thread resources corresponding to the device, preventing memory leaks.

[0103] In one optional embodiment, if a user needs to switch plugin versions, they can directly select the new plugin version and click the switch version button. The system can automatically execute the unbinding process of the current plugin, then execute the binding process of the new plugin, and finally, if the device is enabled, resume the device's data collection task to ensure uninterrupted data collection.

[0104] In some optional implementations, the above method further includes: Step a1: When a modification instruction uploaded by the user is received, the first device information set is modified based on the modification instruction.

[0105] In one optional embodiment, users can perform various operations on registered devices, such as editing, deleting, enabling / disabling, and filtering and querying devices by device type, manufacturer, site, etc.

[0106] In one optional embodiment, when processing an edit operation, the new energy equipment operation and maintenance system 1 will re-verify the legality of the changed fields after receiving a modification request. Once confirmed to be correct, it will update the database and configuration center cache to ensure that the modifications take effect in real time. Specifically, only non-critical fields such as ipAddress, port, and location are allowed to be modified; critical fields such as deviceId and deviceType are not supported for modification to prevent disruption of subsequent relationships.

[0107] In one optional embodiment, when processing a deletion operation, logical deletion or physical deletion is supported. However, before deletion, it is checked whether the device is bound to a protocol plugin. If it is bound, the system prompts the user to unbind the protocol plugin before performing the deletion to avoid invalid association issues. Logical deletion indicates marking the device as deleted; physical deletion indicates complete removal from the database.

[0108] Furthermore, regarding status switching, modifying the `enabled` field can synchronously notify the subsequent data collection and scheduling module, causing disabled devices to suspend their data collection tasks. When performing filtering queries, the system will use database indexes to perform multi-dimensional and rapid filtering, returning a list of devices and their key statuses to the user.

[0109] In some optional implementations, the above method further includes: Step b1: When the second protocol plugin and hot deployment update instruction uploaded by the user are received, the second protocol plugin is loaded.

[0110] The second protocol plugin and the first protocol plugin are different plugins of the same protocol.

[0111] Step b2: Once the second protocol plugin is loaded, perform a grayscale update on the new energy devices corresponding to the first protocol plugin and obtain the updated data collection status of the new energy devices.

[0112] Step b3: If the data acquisition status of the updated new energy equipment is not abnormal, update the first protocol plugin using the second protocol plugin.

[0113] In one optional embodiment, when a user uploads a new version of the plugin for the same protocol and selects hot deployment update, the system first loads the new version of the plugin according to the plugin loading process. After loading is complete, the system queries the list of devices currently bound to the old version of Modbus.

[0114] Furthermore, the system supports users selecting specific devices for version switching first, i.e., a canary rollout update. Specifically, during the canary rollout update process, the system can closely monitor the data collection status of the devices after the switch. If no anomalies occur, users can choose to switch all devices bound to the old version plugin to the new version; if anomalies occur, the system can quickly roll back to the old version, ensuring stable system operation.

[0115] In some optional implementations, step S203 above includes: Step S2031: Based on the second equipment information set, obtain the fourth equipment information set of multiple target new energy equipment.

[0116] In one optional embodiment, multiple target new energy devices that are in an enabled state and have been bound to valid protocol plugins are selected from the second device information set, and their key communication and association information is extracted to form a corresponding fourth device information set.

[0117] Step S2032: Based on the fourth device information set, generate multiple acquisition tasks for multiple target new energy devices.

[0118] In an optional embodiment, task parameters can be defined for each target device according to a predefined acquisition task structure. These parameters may include a unique task identifier (taskId), associated target device ID (deviceId), associated protocol plugin ID (pluginId), acquisition cycle (collectionCycle), associated target point table ID (pointTableId), task timeout, and initial retry count (retryCount).

[0119] Furthermore, the fourth device information set is traversed to generate an independent acquisition task for each device, with the task parameters corresponding one-to-one with the device information. Then, the tasks are grouped according to device type or protocol type.

[0120] Furthermore, the grouped data collection tasks are registered with the corresponding data collection scheduling engine within the system.

[0121] Step S2033: Based on the preset non-blocking scheduling and exponential backoff retry strategy, multiple acquisition tasks are executed using threads to obtain multiple raw data frames from multiple target new energy devices.

[0122] In one optional embodiment, the system creates thread pools grouped by device type, and each thread pool is configured with an independent number of core threads to avoid resource contention among different types of device acquisition tasks.

[0123] Furthermore, the system's data acquisition scheduling engine triggers tasks according to the data acquisition cycle and submits the tasks to the corresponding thread pool.

[0124] For example, when the wind turbine data acquisition cycle is reached, an idle thread in the wind turbine data acquisition thread pool acquires the Modbus_WTG001 task. Then, the thread calls the plugin's communication interface through the protocol plugin instance associated with the task to prepare to initiate data acquisition.

[0125] In one optional embodiment, a non-blocking task scheduling mode is adopted. If a device times out, the thread can mark the task as temporarily failed and release thread resources to avoid the thread pool being exhausted due to a single task blocking. Furthermore, timed-out tasks can enter a retry queue and be rescheduled according to an exponential backoff strategy. If the retry fails, an alarm is triggered.

[0126] In one optional embodiment, the data acquisition scheduling engine monitors device status changes in the configuration center in real time. If a device changes from enabled to disabled, the data acquisition task for that device is immediately terminated, removed from the thread pool, and associated resources are released. If the data acquisition cycle is modified, the trigger time of the task is updated, and the task is executed according to the new configuration in the next cycle. If a new device is added, a new data acquisition task is automatically generated and submitted to the corresponding thread pool to achieve data acquisition as soon as it is configured.

[0127] In one alternative embodiment, a connection is established with the device and raw data frames are obtained through the communication interface of the protocol plugin.

[0128] In one alternative embodiment, the protocol plugin establishes a connection with the device using the corresponding communication method based on the protocol type bound to the device. The connection logic differs for different protocols.

[0129] For example, when a thread calls the `validateConnection()` method of a pull-based protocol (such as Modbus, IEC104, JDBC), it first verifies whether the current connection is valid. If the connection is invalid, the plugin re-establishes the connection according to the device communication parameters.

[0130] The Modbus-TCP protocol establishes a TCP connection with the device's IP port via a socket; the IEC104 protocol establishes a client connection based on the host IP + port + APCI parameters, and enters the data transmission state after completing the handshake; the JDBC protocol connects to the device's built-in database via a JDBC URL, and obtains a database connection after verifying the username and password.

[0131] Furthermore, if the connection fails to be established, the plugin returns a connection failure status, the thread marks the task as failed and triggers an alarm, and at the same time updates the device status to offline.

[0132] Furthermore, for event-based protocols (such as MQTT), the protocol plugin (implemented in Eclipse Paho) ​​establishes a long connection with the device-side MQTT Broker and subscribes to the corresponding topics on the device when the system starts up.

[0133] Furthermore, the data collection task does not need to actively initiate a connection; it only needs to listen for messages pushed by the Broker. That is, when the device publishes data, the plugin receives the message and caches it in a local message queue, waiting for subsequent parsing. Moreover, if the long-lived connection is broken, the plugin automatically triggers a reconnection mechanism. During the reconnection period, received device messages are cached on the device to prevent data loss.

[0134] In an optional embodiment, for pull-type protocol data, the thread extracts information such as the register address and function code of the data points to be collected from the point table configuration set associated with the task, i.e., the target point table configuration information set, and the protocol plugin constructs the original data request frame.

[0135] For example, taking Modbus as an example, the system constructs the following message: [Transaction ID][Protocol ID][Length][Unit ID][Function Code][Start Address][Quantity]. Here, the start address and quantity are determined by the registerAddress and the number of collection points in the point table.

[0136] Furthermore, the plugin sends a request frame through the established communication connection and waits for the device to return a response frame.

[0137] Furthermore, after processing the request, the device returns the original response frame, which is multiple target data frames.

[0138] In one optional embodiment, for event-type protocol data, the original message pushed by the device is extracted from the local message queue, and then the message is format-validated. If the validation passes, it is marked as pending parsing; if the validation fails, it is logged and discarded.

[0139] Step S2034: Parse multiple raw data frames and extract multiple target data frames based on the target point table configuration information set to obtain multiple target data frames.

[0140] In one alternative embodiment, the protocol plugin can call the corresponding decoding logic according to its own protocol type and decompose the original data frame into recognizable fields.

[0141] Furthermore, the plugin can associate the decoded values ​​with the data point names and extract the corresponding multiple target data frames based on the mapping relationship between the registerAddress / JSON field and the pointName in the point table.

[0142] In an alternative embodiment, the original values ​​can also be calibrated according to a point scale.

[0143] In an optional embodiment, if there are no abnormalities in the extraction process, the data point quality is marked as GOOD; if the decoding of a data point fails, it is marked as BAD.

[0144] Step S2035: Encapsulate multiple target data frames to obtain the original device dataset.

[0145] In one optional embodiment, all valid data points after parsing are encapsulated into a JSON structure according to a preset uniform format to form the corresponding original device dataset.

[0146] Furthermore, the original device dataset may include device ID, timestamp, data field, quality status, etc.

[0147] In one optional embodiment, if it is a single device single acquisition, then a target data frame of the device is directly encapsulated into a raw device dataset; if it is a multi-device single acquisition, it can be grouped by deviceId, and a raw device dataset can be generated for each device.

[0148] In some optional implementations, step S204 above includes: Step S2041: Using a preset domain standard data model, the original device dataset is mapped to obtain the first device dataset.

[0149] In one optional embodiment, the preset domain standard data model represents a structured data benchmark that is predefined and conforms to industry business logic and data specifications in order to achieve data unification of heterogeneous devices in the new energy field. It is used to provide a unified data language for new energy devices of different brands and protocols, and to ensure that the raw data collected can be converted into standardized data that can be integrated across devices and directly applied according to consistent rules.

[0150] In one optional embodiment, the deviceId is extracted from the original device dataset, and the deviceId is associated with the stored device type. Then, a predefined model corresponding to the device type is retrieved from the domain standard data model library. Furthermore, the predefined model includes mapping relationships between standard fields, field meanings, units, and data types.

[0151] Furthermore, the new energy equipment operation and maintenance system 1 can also read the field mapping rule base from the configuration center. This field mapping rule base can originate from the manufacturer's standard mappings, user-manually bound original fields to standard fields via a web interface, and semantic configurations. Semantic configuration indicates that if the original field has no preset mapping, the system recommends a standard field through NLP semantic recognition, and generates a rule after user confirmation.

[0152] Furthermore, the data field of the original device dataset is traversed, and the original field names are replaced with standard fields according to the mapping rules to obtain the corresponding first device dataset.

[0153] In an optional embodiment, original fields without matching standard fields are marked as non-standard fields and stored in the extended_data extended field to avoid data loss.

[0154] Step S2042: Perform unit conversion and dimension normalization on the first device dataset to obtain the second device dataset.

[0155] In one optional embodiment, because different manufacturers' devices use inconsistent unit definitions (e.g., temperature in °C or Fahrenheit, electricity in Wh or kWh), the system needs to automatically perform unit conversion. Each field maintains original unit and target unit fields: {"value":138000,"unitOriginal":"Wh","unitTarget":"kWh","conversionRule":"divide_1000"}.

[0156] Wherein, value represents the numerical value, i.e. the original measurement data to be converted to units; unitOriginal represents the original unit; unitTarget represents the target unit; and conversionRule represents the conversion rule.

[0157] In one optional embodiment, the conversion method may include proportional conversion, temperature conversion, displacement conversion, and timestamp conversion, etc. Furthermore, the corresponding second device dataset can be obtained through the conversion.

[0158] In an optional embodiment, numerical data can also be processed with a unified precision format to ensure that data from different devices have the same numerical granularity. Supported precision control methods include retaining decimal places, automatic zero padding, error amplification / reduction, and configuring a precision field to control precision.

[0159] Step S2043: Perform enumeration value mapping and semantic normalization on the second device dataset to obtain the third device dataset.

[0160] In one optional embodiment, the original numerical encoding or bitmap of the status / switch fields in the second device dataset is converted into recognizable standard semantic text through a preset enumeration mapping table, and the processed third device dataset is obtained, which eliminates semantic heterogeneity and improves data readability.

[0161] For example, the new energy equipment operation and maintenance system 1 can read the enumeration mapping table library from the configuration center and classify it according to the standard field - equipment type. Then, iterates through the data field of the second equipment dataset, filters out the enumeration standard fields, and maps them through the mapping table to obtain the mapped equipment data.

[0162] Furthermore, the standard semantics and original values ​​of enumerated fields are incorporated into the data structure, while the original values ​​of non-enumerated fields are retained, and then the corresponding third-party device dataset is formed through integration.

[0163] In one optional embodiment, for status or switch fields, the original data is mostly numbers or bitmaps, lacking semantic information, and needs to be uniformly mapped to recognizable text. This is configured through an enumerated mapping table: {"field":"status_code","rawValue":2,"mapping":{"0":"Stopped","1":"Running","2":"Fault","3":"Maintenance"},"standardizedValue":"Fault"}.

[0164] Wherein, field represents the field name, i.e., the standard field name; rawValue represents the raw value, i.e., the numeric code; mapping represents the mapping table, i.e., the correspondence between the raw value and the standard semantics; and standardizedValue represents the standardized value.

[0165] Furthermore, by enumerating the mapping table as described above, the processed third device dataset can be obtained.

[0166] Step S2044: Perform quality assessment and invalid value processing on the third device dataset to obtain the target device dataset.

[0167] In one optional embodiment, the data credibility of the third device dataset is evaluated through multi-dimensional quality detection, while quality levels (GOOD / BAD / STALE) are marked, and invalid values ​​are processed according to a preset strategy, ultimately outputting a high-quality target device dataset.

[0168] In one optional embodiment, a data quality control mechanism is introduced during the standardization process to improve data credibility. This quality control may include strategies such as outlier detection, constant value detection, discontinuity value identification, timestamp validity detection, and data format error detection. The system provides quality assessment levels: GOOD, BAD, and STAL. Outliers can be selected using three strategies: "zeroing," "filtering," and "retaining the mark."

[0169] Furthermore, through the above processing, a high-quality target device dataset can be finally output.

[0170] In some optional implementations, the above method further includes: Step c1 involves using a graphical configuration interface to construct a visual acquisition link for multiple target new energy devices, enabling the client to locate faults in multiple target new energy devices based on the visual acquisition link.

[0171] In one optional embodiment, a visual acquisition link from the device to the data standard model is constructed through a graphical configuration interface, and the link's running status, communication performance, and abnormal nodes are displayed in real time during runtime, which can improve system transparency and operational efficiency. Furthermore, each data acquisition link in the system is described in JSON structure and uniformly stored in a database configuration table for easy parsing, version management, and dynamic loading.

[0172] In one optional embodiment, the front-end is implemented using Vue 3 + Element Plus to create a configuration page. A node editor component library provides visual drag-and-drop functionality, supporting interactive editing of nodes and connections, facilitating user-built data collection topology. When the user clicks "Save" or "Publish," the link JSON is parsed by the back-end into a data collection task definition and dynamically registered to the data collection engine, taking effect without a restart. During runtime, the front-end periodically retrieves the status and performance metrics of each node via a REST API and adjusts visual attributes such as node color and connection thickness in real time based on a data visualization library, accurately reflecting the health status of the links. It also provides various component formats such as list views and indicator line charts to meet the multi-dimensional monitoring and analysis needs of operations personnel for link structure and operational data.

[0173] For example, based on the flowchart modeling concept, the key links in the data acquisition chain are abstracted as component nodes. The node types are shown in Table 2 below: Table 2. Node Types and Descriptions

[0174] Furthermore, each node is displayed on the canvas in the form of a graphical component, and the connection between nodes represents the direction of data flow. Each link is a directed graph structure composed of multiple nodes and their connection relationships.

[0175] Furthermore, the front end uses an interactive flowchart engine to render the link canvas, supporting node dragging, automatic alignment, connection verification, and attribute panel editing; clicking on a node will pop up a parameter configuration window, supporting field filling, template selection, and parameter verification; connection operations automatically verify the legality of the connection, such as prohibiting devices from directly connecting to forwarding nodes; link templates can be saved and reused; after editing, clicking "Publish Link" will automatically generate the corresponding data collection task and forwarding process.

[0176] Furthermore, through the above operations, a corresponding visual acquisition chain can be constructed.

[0177] In some optional implementations, after a link is published, the system monitors the operation of each link component and provides real-time feedback on its operational status via a graphical interface. All status information originates from the data acquisition, scheduling, and logging system, with a real-time refresh rate every 5 seconds. Historical trend viewing is supported, and the system offers switchable view modes: a link topology view and a list detail view. Each connection can be clicked to view metrics such as transmission rate, success rate, and last data acquisition time.

[0178] Furthermore, client 3 can access the link monitoring view and locate faults based on the constructed visualized link. For example, if a device fails to collect data, client 3 can visually view abnormal nodes in the link and quickly locate the faulty link.

[0179] Furthermore, clicking on abnormal nodes allows users to view detailed logs, which in turn helps maintenance personnel to conduct accurate troubleshooting.

[0180] In some optional implementations, the above method further includes: Step d1 involves monitoring the operation of each component in the visualization acquisition process and acquiring multiple real-time operational status information.

[0181] Step d2 involves updating the visualized acquisition link based on multiple real-time operational status information.

[0182] In one optional embodiment, the operating status and performance indicators of each component in the visualization acquisition link, namely device / protocol / point table / standard model / forwarding node, are collected in real time through multi-dimensional interfaces. Based on the collected real-time operating status information, the link health status is fed back in real time in the front-end visualization interface by adjusting visual attributes such as node color, connection style, and indicator display, thereby ensuring that operation and maintenance personnel obtain the latest and most accurate link status.

[0183] In some alternative implementations, the method further includes: storing the target device dataset in a local cache when an abnormal situation occurs.

[0184] Abnormal situations may include network connection errors, data forwarding failures, platform response delays exceeding thresholds, and offline mode.

[0185] In one alternative embodiment, in the event of network jitter or link interruption, the collected data will be written to the local cache in chronological order to ensure that the field data is not lost.

[0186] For example, the system will automatically enable local caching when any of the following occurs: Table 3. Abnormal Situations and Judgment Basis

[0187] Furthermore, the cache uses a lightweight storage engine for persistence and has the following structure: {"taskId":"modbus_wtg001","deviceId":"WTG001","timestamp":"2025-07-24T12:12:00Z","data":{"active_power":321.5,"wind_speed":5.4},"syncStatus":"PENDING"}.

[0188] Among them, taskId represents the data acquisition task ID; deviceId represents the unique identifier of the device; timestamp represents the original data acquisition time; data represents the core data content to be cached, i.e. the device monitoring data that needs to be cached in case of an anomaly; active_power represents the active power; wind_speed represents the wind speed; syncStatus represents the synchronization status, i.e. the cached data return status, indicating the current return progress of the cached data; and PENDING represents pending synchronization.

[0189] Furthermore, each cached record is an independent data object, stored in chronological order, with a maximum cache capacity (e.g., 500MB or 7 days of data), supports FIFO cleanup strategies, and each record is uniquely identified for easy deduplication.

[0190] In an optional embodiment, the cache management module also has the following capabilities: Table 4. Cache Management and Exception Recovery Strategies

[0191] This embodiment provides a new energy equipment operation and maintenance system, such as Figure 1 As shown, the new energy equipment operation and maintenance system 1 is connected to the user terminal 2 and the client terminal 3 respectively. Furthermore, the new energy equipment operation and maintenance system 1 includes: an access module 10, a data acquisition and parsing module 20, a data standardization module 30, and a storage and forwarding module 40.

[0192] Among them, the access module 10 is used for protocol adaptation to realize unified access of industrial equipment; the acquisition and parsing module 20 is used for data standardization processing to map the raw data into a unified model; the data standardization module 30 is used for link visualization configuration and monitoring, and graphically displays the acquisition path and operating status; the store and forward module 40 is used for local caching and multi-channel forwarding, supporting offline caching, breakpoint resume and reliable output.

[0193] For specific handling procedures, please refer to the relevant descriptions in the above-mentioned new energy equipment operation and maintenance methods, which will not be repeated here.

[0194] The new energy equipment operation and maintenance system provided in this embodiment achieves full-process coverage of configuration, data collection, standardization, and forwarding through an integrated modular design, reducing the complexity of system deployment and maintenance. At the same time, the collaborative work between modules ensures the implementation of new energy equipment operation and maintenance methods, thereby helping to support the data needs of the entire new energy equipment operation and maintenance process.

[0195] In one example, a multi-protocol data acquisition, storage, and forwarding method with data standardization and link visualization is presented. Addressing the challenges of heterogeneous device communication protocols, inconsistent data formats, and the "black box" nature of the acquisition link in the new energy industry, a comprehensive solution integrating protocol fusion, data standardization processing, graphical link configuration, real-time monitoring, and data caching and forwarding is proposed. This method constructs a pluggable, configurable, and visualized integrated system. It unifies the access of multiple communication protocols through a protocol adaptation layer, performs structural standardization conversion through data models and point-table-driven approaches, and combines a graphical interface to realize link configuration and real-time status visualization, thereby improving system integration efficiency, data consistency, and operational transparency. The overall architecture is as follows: Figure 3 As shown.

[0196] The system mainly includes the following functional modules: multi-protocol adaptation to achieve unified access for industrial equipment; data standardization processing to map raw data into a unified model; link visualization configuration and monitoring to graphically display the acquisition path and operating status; local caching and multi-channel forwarding to support offline caching, breakpoint resume and reliable output.

[0197] Furthermore, the above methods specifically include: 1. Device access and protocol configuration.

[0198] Built on a lightweight web service framework, it employs a modular container mechanism to host network interfaces such as HTTP and WebSocket. Communication capabilities such as MQTT (Message Queuing Telemetry Transport Protocol), serial port, and JDBC (Java Database Connectivity) are encapsulated as independent protocol adapter modules. Each adapter module is automatically registered as a service component through a runtime plugin discovery mechanism and can be dynamically started, stopped, and hot-updated by a centralized configuration center, thereby achieving on-demand loading and versioned management of protocol capabilities. The specific process is as follows: (1) Equipment information modeling and registration process.

[0199] The system provides standardized device registration and configuration interfaces. Users can enter device information through a web interface or API. A typical data structure is as follows: {"deviceId":"WTG001","deviceName":"Wind Turbine 1#","deviceType":"Wind Turbine Generator Set","vendor":"Goldwind","location":"Site A-1","protocolType":"Modbus","ipAddress": "192.168.10.101","port":502,"enabled":true}.

[0200] Device types support custom classification, such as inverters, fans, combiner boxes, etc.; communication parameters are automatically adjusted according to different protocols; all device information can be imported via CSV or Excel files, and batch editing and deletion operations are possible.

[0201] (2) Protocol-driven plugin loading and binding mechanism.

[0202] The system adopts a plug-in protocol driver framework, with each protocol encapsulated as an independent plug-in and having a unified registration interface. public interface ProtocolAdapter { String getProtocolType(); / / Get the protocol type boolean validateConnection(ProtocolConfig config); / / Validate connection List <datapoint>readPoints(Device device, List <datapointconfig>pointConfigs);} / / Read data points.

[0203] Protocol plugins are registered in JAR format, and the configuration center can dynamically identify their new energy equipment metadata. After loading, the plugin can be bound to a specified new energy device via the UI. The system has built-in plugins for common protocols such as JDBC, Modbus, IEC104, MQTT, and HTTP, and supports user-defined private protocol plugins. To support hot deployment and version coexistence of protocol plugins, the system management component assigns an independent URLClassLoader to each plugin JAR and implements class isolation through parent priority inversion. Plugin loading is managed by "PluginManager", which dynamically registers or unregisters Spring Beans using BeanDefinitionRegistry and controls orderly start and stop through SmartLifecycle. Plugin metadata includes {name, version, sha256, minCoreVersion, capabilities[]}. Before loading, user-defined protocol plugins undergo hash full signature verification and version compatibility verification. Multiple versions of the same protocol are allowed to coexist, and the routing version is selected by binding the protocol plugin to the corresponding device. To avoid memory leaks, the uninstallation process includes: stopping the scheduled task, releasing network resources, unregistering MBeans, removing Bean definitions, and closing the ClassLoader.

[0204] To address plugin conflict scenarios, a lightweight governance approach is adopted based on existing plugin loading, class isolation, and hot deployment: "pre-detection of conflicts, resource isolation, on-demand communication, and rollback capability." Before loading, dependencies and resources (ports or serial ports, point tables, and write channels) are verified, and loading is rejected if they fail. During runtime, independent quotas (threads, connections, speed, and cache) are set for each plugin and decoupled by default. Communication is only achieved through event bus or service registration when necessary. The lifecycle is unified with canary upgrades or one-click rollback. Conflicts are automatically downgraded or isolated, ensuring long-term stable parallelism of multi-protocol plugins.

[0205] (3) Point table modeling and parsing configuration.

[0206] Each device needs to define its collected data points, which are entered through a point table template or online configuration. The data structure is as follows: {"pointName":"Power Generation","registerAddress":30001,"functionCode":3,"dataType": "FLOAT32","scale":0.01,"unit":"kW","standardField":"active_power","precision":2}.

[0207] The system provides a point table template library, supporting the maintenance of standard templates by manufacturer and model. Point table fields include register address, function code, data type, multiplier, unit, and target field mapping. It supports configuration verification functions to ensure logical correctness, such as avoiding duplicate addresses or invalid function codes. Point tables can be edited via a web interface, Excel import, or JSON batch import. Point tables are strongly bound to the protocol driver, and the field structure can be automatically switched according to the protocol type.

[0208] 2. Protocol acquisition and data parsing.

[0209] The goal is to drive data acquisition tasks to periodically access devices and parse the returned raw data packets, extracting standardized fields for subsequent processing, based on completed device access and point table configuration. Its core includes key steps such as task scheduling, protocol parsing, data structure encapsulation, exception handling, and logging.

[0210] It supports mainstream industrial communication protocols such as Modbus, IEC104, MQTT, HTTP, and JDBC. Data acquisition and scheduling are uniformly based on Spring TaskScheduler, enabling lightweight triggering of periodic polling protocols. Each protocol reuses mature open-source libraries: Modbus uses Modbus4J, IEC104 uses open104, MQTT relies on Eclipse Paho, the HTTP interface is implemented through WebClient, and JDBC directly accesses the data source.

[0211] Pull-based protocol data parsing utilizes a Reactor Flux-based data processing pipeline, breaking down "decoding, mapping, and quality marking" into sequential, purely functional processing steps. This ensures non-blocking execution and supports backpressure, resulting in a clear and controllable processing chain. Event protocols such as MQTT are directly injected into FluxSink via callbacks, naturally supporting non-blocking and high concurrency. Device parameters and connection configurations are declared using YAML and uniformly managed by Spring Cloud Config, enabling centralized configuration management and remote updates. This approach is suitable for complex industrial scenarios involving multi-protocol integration, standard data acquisition, and distributed deployment. The specific process is as follows: (1) Data collection task scheduling mechanism.

[0212] The system uses a timed task scheduler to manage all device acquisition tasks in a unified manner. The scheduler supports periodic execution with second-level accuracy. It uses a concurrent thread pool to schedule tasks in groups by device to avoid blocking between tasks. It supports starting, stopping, modifying, and deleting tasks, and configuration changes can take effect in real time.

[0213] (2) Raw data frame acquisition and communication interface.

[0214] The acquisition thread is configured according to the task and obtains raw data frames by calling the communication method through the protocol adapter. Taking Modbus as an example, the system constructs the following message: [Transaction ID][Protocol ID][Length][Unit ID][FunctionCode][Start Address][Quantity]. For MQTT-like protocols, it passively receives data by listening to the subscribed topics.

[0215] (3) Original message parsing and data point extraction.

[0216] The returned data frame is decoded by the corresponding protocol driver, and the data fields are extracted by combining the point table configuration information. The decoding logic supports data types including integer, decimal, boolean and string.

[0217] (4) Data structure encapsulation.

[0218] All collected data is ultimately encapsulated into a unified data structure: {"deviceId":"WTG001","timestamp":"2025-07-24T12:01:05Z","data":{"Power generation":321.5,"Nacelle temperature":45.1,"Wind speed":5.8},"quality":"GOOD"}.

[0219] The system uniformly adds a standard UTC timestamp to each batch of data; if the device returns its own timestamp, it is saved as a reference field; it supports calculating the data change rate to determine the validity of the data and mark the quality status, such as GOOD, BAD, or STALE.

[0220] 3. Data standardization processing.

[0221] The goal of this process is to transform the raw device data collected through the protocol into a standard data model that is semantically consistent, structurally standardized, and formatted uniformly, in order to support subsequent cross-device integration, visualization analysis, and platform forwarding. Its core components include modules such as field mapping, unit conversion, enumeration normalization, precision control, and quality inspection.

[0222] Field mapping, unit conversion, and enumeration adaptation are all handled by a static code generation mapper automatically generated by the mapper. Combined with a compile-time annotation processor, getters, setters, and constructors are automatically generated, resulting in a concise and clear entity class structure. Unit conversion formulas and threshold rules are written to the configuration center in parameterized form, retrieved periodically or in real-time by the backend, and injected into memory. The Java logic uses a built-in expression parser for execution, ensuring flexible and type-safe rule configuration. Frequently used dictionary information is cached locally for faster access, while Redis is used for remote sharing and centralized updates, forming a high-performance, easily maintainable two-level caching system. Data quality tags (such as GOOD, STALE, BAD) are encapsulated as enumeration types and uniformly persisted to the `quality` field, providing support for subsequent alert rules and quality assessment reports. The specific process is as follows: (1) Standard data model and field mapping mechanism.

[0223] The system maintains a unified domain standard data model. Each type of equipment (such as wind turbines and photovoltaic inverters) has a predefined model. Example: active_power FLOAT kW active power.

[0224] Each point table field is bound to a standard field through configuration or template: {"pointName":"Power Generation","standardField":"active_power"}. The system supports automatic field recommendation and matching, and the field mapping information can be centrally maintained on the platform and supports versioning.

[0225] (2) Unit conversion and dimension normalization mechanism.

[0226] Because different manufacturers use different unit definitions (e.g., temperature in °C or Fahrenheit, electricity in Wh or kWh), the system needs to automatically perform unit conversions. Each field maintains original and target unit fields: {"value":138000,"unitOriginal":"Wh","unitTarget":"kWh","conversionRule":"divide_1000"}.

[0227] The system supports conversion methods including proportional conversion, temperature conversion, displacement conversion, and timestamp conversion. All conversion rules are built into the unit conversion engine and support custom script extensions.

[0228] (3) Data precision processing mechanism.

[0229] The system supports uniform precision format processing for numerical data, ensuring that data from different devices have the same numerical granularity. Supported precision control methods include retaining decimal places, automatic zero padding, error amplification / reduction, and configuring a precision field to control precision.

[0230] (4) Enumeration value mapping and semantic normalization.

[0231] For status or switch fields, the raw data is mostly numbers or bitmaps, lacking semantic information, and needs to be uniformly mapped to recognizable text. This is configured through an enumerated mapping table: {"field":"status_code","rawValue":2,"mapping":{"0":"Out of service","1":"Running","2":"Fault","3":"Maintenance"},"standardizedValue":"Fault"}.

[0232] (5) Data quality assessment and invalid value handling.

[0233] To enhance data credibility, the system incorporates a data quality control mechanism during the standardization process. Quality control includes strategies such as outlier detection, constant value detection, discontinuity value identification, timestamp validity detection, and data format error detection. The system provides quality assessment levels: GOOD, BAD, and STAL. Outliers can be handled using three strategies: "zeroing," "filtering," or "retaining the mark."

[0234] (6) Standardized results output and examples.

[0235] The standardized data structure is as follows: {"deviceId":"WTG001","timestamp":"2025-07-24T12:10:00Z","data":{"active_power":{"value":321.54,"unit":"kW","quality":"GOOD "},"status_code":{"value":"Fault","raw":2,"quality":"GOOD"},"nacelle_temp":{"value":-999.0,"quality":"BAD","reason":"Temperature out of limit"}}}.

[0236] 4. Link visualization.

[0237] A graphical configuration interface is used to build a visualized data acquisition chain from devices to a standard data model. During runtime, the system displays the chain's operational status, communication performance, and abnormal nodes in real time, improving system transparency and operational efficiency. Each data acquisition chain in the system is described using a JSON structure and stored uniformly in a database configuration table for easy parsing, version management, and dynamic loading. The front-end configuration page is implemented using Vue 3 + Element Plus, and a node editor component library provides visual drag-and-drop functionality, supporting interactive editing of nodes and connections, facilitating user-built acquisition topologies. When the user clicks "Save" or "Publish," the chain JSON is parsed by the back-end into an acquisition task definition and dynamically registered to the acquisition engine, taking effect without a restart. During runtime, the front-end periodically retrieves the status and performance metrics of each node via a REST API and adjusts visual attributes such as node color and connection thickness in real time based on a data visualization library, accurately reflecting the chain's health status. Multiple component formats, such as list views and indicator line charts, are provided to meet the multi-dimensional monitoring and analysis needs of operations personnel for chain structure and operational data. The specific process is as follows: (1) Link modeling and component node definition.

[0238] The system is based on the flowchart modeling concept, and the key links in the data acquisition link are abstracted as component nodes. The node types are shown in Table 2 above.

[0239] Each node is displayed on the canvas as a graphical component, and the lines between nodes represent the direction of data flow. Each link is a directed graph structure composed of multiple nodes and their connection relationships.

[0240] (2) Graphical configuration interface design.

[0241] The front end uses an interactive flowchart engine to render the link canvas, supporting node dragging, automatic alignment, connection verification, and attribute panel editing; clicking on a node will pop up a parameter configuration window, supporting field filling, template selection, and parameter verification; connection operations automatically verify the legality of the connection, such as prohibiting devices from directly connecting to forwarding nodes; link templates can be saved and reused; after editing, clicking "Publish Link" will automatically generate the corresponding data collection task and forwarding process.

[0242] (3) Visualization mechanism for running link status.

[0243] After the link is published, the system monitors the operation of each link component and provides real-time feedback on its operational status on the graphical interface. All status information comes from the data acquisition, scheduling, and logging system, with a real-time refresh every 5 seconds. Historical trend viewing is supported, and the view modes can be switched between link topology view and list detail view. Each connection can be clicked to view metrics such as transmission rate, success rate, and last data acquisition time.

[0244] 5. Local caching and data forwarding.

[0245] To address common issues in data acquisition scenarios involving new energy industrial equipment, such as network fluctuations, link interruptions, and platform unavailability, a highly reliable local data caching and intelligent forwarding mechanism is constructed to ensure the integrity, continuity, and fault tolerance of data transmission. In the event of network jitter or link interruption, acquired data is written to the local cache in chronological order, ensuring no data loss. After network recovery, the system automatically triggers a batch backhaul process, employing a priority-based channel strategy for data transmission: prioritizing high-throughput uploading via MQTT, then downgrading to HTTP POST. The entire uploading process is driven by Spring Retry, with the number of retries and the fallback interval configured uniformly in application.yml to ensure elasticity and controllability. For batches that fail after exceeding the retry threshold, the system uses the @Recover method to capture them and record them in the logs or database, facilitating troubleshooting by maintenance personnel and maximizing data integrity and traceability. The specific process is as follows: (1) Local cache triggering mechanism.

[0246] When any of the situations listed in Table 3 above occurs, the system will automatically enable local caching. Furthermore, the caching mechanism is implemented at the edge acquisition end, isolating the cache space at the task granularity level, with each acquisition task caching its data separately.

[0247] (2) Cache structure design.

[0248] The cache uses a lightweight storage engine for persistence and has the following structure: {"taskId":"modbus_wtg001","deviceId":"WTG001","timestamp":"2025-07-24T12:12:00Z","data":{"active_power":321.5,"wind_speed":5.4},"syncStatus":"PENDING"}.

[0249] Furthermore, each cached record is an independent data object, stored in chronological order, with a maximum cache capacity (e.g., 500MB or 7 days of data), supports FIFO cleanup strategies, and each record is uniquely identified for easy deduplication.

[0250] (3) Cache management and exception recovery strategy: The cache management module has the capabilities shown in Table 4 above.

[0251] (4) Multi-target forwarding mechanism.

[0252] The system supports forwarding a single piece of data to multiple target systems simultaneously, including via MQTT Broker, HTTP / RESTful interfaces, databases, and files.

[0253] (5) Intelligent forwarding and scheduling strategy.

[0254] The system has a built-in forwarding scheduler that supports the strategies shown in Table 1 above, depending on the response capabilities and connectivity status of different targets.

[0255] Furthermore, the scheduler and cache module work together to achieve a complete process of "intelligent judgment, batch uploading, and status marking".

[0256] Furthermore, for the dynamic switching strategy, metrics such as latency, packet loss, bandwidth, and success rate are continuously collected to score each channel. When the primary channel's score falls below a threshold for a sustained period, it automatically switches to the backup channel, and then smoothly switches back after recovery. During the degradation phase, downsampling, batch or asynchronous transmission, or local buffering are performed according to the strategy. The buffer is managed by blocks and sequence numbers, with block-level compression and encryption, and integrity checks and idempotent retransmissions are included to ensure reliable forwarding even in weak network conditions.

[0257] (6) Forwarding status feedback and exception handling.

[0258] The system provides a forwarding status receipt mechanism to ensure that data is either "delivered" or receives a "failure alert": A. Each forwarding target returns a status (HTTP 200 / MQTT PUBACK); B. Status is written to the forwarding log, and exceptions are written to the event center; C. If consecutive failures reach a threshold, the channel will be automatically switched or the system will be downgraded to cache mode. D. The UI displays visual metrics such as forwarding status, cache backlog, latest upload time, and success rate.

[0259] This example provides a multi-protocol data acquisition, storage, and forwarding method for data standardization and link visualization, which has the following effects: 1. Achieve unified access and standardized data processing for multiple communication protocols, thereby improving the efficiency of data fusion and utilization from heterogeneous devices.

[0260] 2. Provides visual configuration and status monitoring capabilities for the data acquisition link, enhancing the system's maintainability and fault location efficiency.

[0261] 3. By using local caching and multi-channel forwarding mechanisms, the stability and reliability of data collection and transmission are ensured.

[0262] Furthermore, the above methods help enterprises unify the data from new energy equipment of different brands and with different communication protocols into a single system, automatically organizing the disorganized data into a unified standard format, avoiding connection difficulties and data chaos caused by equipment incompatibility. Through a visualized link display, enterprise operations and maintenance personnel can clearly see the entire process of each data point from collection to upload, enabling rapid location and handling of faults and significantly improving operational efficiency. In cases of network instability or poor signal at remote sites, the system can automatically cache data and retransmit it after network recovery, ensuring that critical production data is not lost or interrupted. Overall, this technology makes enterprise data more reliable, transparent, and easy to use, providing a stable data foundation for applications such as production monitoring, energy efficiency analysis, and equipment health management.

[0263] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.< / datapointconfig> < / datapoint>

Claims

1. A method for the operation and maintenance of new energy equipment, characterized in that, A new energy equipment operation and maintenance system is used, wherein the new energy equipment operation and maintenance system is connected to both a user terminal and a client terminal; the method includes: Receive the first device information set, the first protocol plugin, and the first point table configuration information set uploaded by the user terminal; Based on the first device information set, the first protocol plugin and the first point table configuration information set are configured to obtain the second device information set and the target point table configuration information set. Based on the second device information set, the target point table configuration information set, and the preset non-blocking scheduling and exponential backoff retry strategy, the original device datasets of multiple target new energy devices are collected using threads, and all of the multiple target new energy devices are in the enabled state. The original device dataset is standardized to obtain the target device dataset; The target device dataset is sent to the client so that the client can manage the operation and maintenance process of the multiple target new energy devices based on the target device dataset and obtain the device operation and maintenance results.

2. The method according to claim 1, characterized in that, Based on the first device information set, the first protocol plugin and the first point table configuration information set are configured to obtain a second device information set and a target point table configuration information set, including: The first device information set and the first point table configuration information set are verified respectively to obtain the third device information set and the second point table configuration information set that pass the verification. The first protocol plugin is parsed to obtain the plugin metadata set; Based on the aforementioned plugin metadata set, the first protocol plugin undergoes signature verification and version compatibility verification. Once the verification passes, the first protocol plugin is loaded using an independent class loader, and the first protocol plugin is bound to the third device information set to obtain the second device information set. The second point table configuration information set is bound to the first protocol plugin and the second device information set to obtain the target point table configuration information set.

3. The method according to claim 1, characterized in that, Based on the second device information set, the target point table configuration information set, and the preset non-blocking scheduling and exponential backoff retry strategy, the raw device datasets of multiple target new energy devices are collected using threads, including: Based on the second device information set, a fourth device information set of the plurality of target new energy devices is obtained; Based on the fourth device information set, multiple acquisition tasks are generated for the multiple target new energy devices; Based on the preset non-blocking scheduling and exponential backoff retry strategy, the thread is used to execute the multiple acquisition tasks to obtain multiple raw data frames of the multiple target new energy devices. The multiple raw data frames are parsed and processed, and based on the target point table configuration information set, the parsed multiple raw data frames are extracted to obtain multiple target data frames; The multiple target data frames are encapsulated to obtain the original device dataset.

4. The method according to claim 1, characterized in that, The original device dataset is standardized to obtain the target device dataset, which includes: The original device dataset is mapped using a pre-defined domain standard data model to obtain a first device dataset. The first device dataset is subjected to unit conversion and dimension normalization to obtain the second device dataset. The second device dataset is subjected to enumeration value mapping and semantic normalization to obtain the third device dataset. The third device dataset is subjected to quality assessment and invalid value processing to obtain the target device dataset.

5. The method according to claim 2, characterized in that, The method further includes: When the second protocol plugin and hot deployment update instruction uploaded by the user are received, the second protocol plugin is loaded. The second protocol plugin and the first protocol plugin are different plugins of the same protocol. Once the second protocol plugin is loaded, perform a grayscale update on the new energy device corresponding to the first protocol plugin, and obtain the updated collection status of the new energy device. If the data collection status of the updated new energy equipment is normal, the first protocol plugin is updated using the second protocol plugin.

6. The method according to claim 2, characterized in that, The method further includes: When a modification instruction is received from the user terminal, the first device information set is modified based on the modification instruction.

7. The method according to claim 1, characterized in that, The method further includes: A graphical configuration interface is used to construct a visual acquisition link for the multiple target new energy devices, so that the client can locate the faults of the multiple target new energy devices based on the visual acquisition link.

8. The method according to claim 7, characterized in that, The method further includes: The operation of each link component in the visualization acquisition link is monitored and multiple real-time operation status information is obtained; The visualization acquisition link is updated based on the multiple real-time operating status information.

9. The method according to claim 1, characterized in that, The method further includes: In the event of an anomaly, the target device dataset is stored in a local cache. Such anomalies include network connection failures, data forwarding failures, platform response delays exceeding thresholds, and offline mode.

10. A new energy equipment operation and maintenance system, connected to a user terminal and a client terminal respectively, for executing the new energy equipment operation and maintenance method according to any one of claims 1 to 9; characterized in that, The system includes: an access module, a data acquisition and parsing module, a data standardization module, and a store-and-forward module.

Images