Multi-protocol compatible wind power master control PLC communication method and system

Abstract

The embodiment of the invention provides a multi-protocol compatible wind power master control PLC communication method and system, and the method comprises the steps: firstly loading and analyzing a descriptor, and converting the descriptor into an internal unified data model; then, through a dynamic communication adaptation and optimization engine, address footprint calculation, sorting and continuous address block merging are performed on the data points, and original point-by-point requests are intelligently aggregated into block requests. After interaction with the PLC, the system efficiently decodes an original binary response message and converts the original binary response message into a semantic data set with a clear service meaning by using a pre-generated response analysis mapping. And then, further extending to upper-layer integration, seamlessly mapping to a standard northbound interface model by utilizing a point ID (Identity) in semantic data, and finally actively pushing data update to all clients in a safe and efficient manner through a publishing / subscribing mechanism of the northbound interface model.

Description

TECHNICAL FIELD

[0001] The embodiment of the present application relates to the field of PLC communication, in particular to a multi-protocol compatible wind power master PLC communication method and system. BACKGROUND

[0002] With the increasing demand for clean energy worldwide, wind power as an important form of renewable energy is rapidly developing in technology and scale. In modern wind farms, the master controller of the wind turbine (usually a programmable logic controller, PLC) is responsible for monitoring the state of the wind turbine, executing control strategies and ensuring its safe and efficient operation. In order to realize centralized monitoring and management of the wind farm, the data of hundreds or thousands of wind turbine master PLCs need to be collected to the upper monitoring and data acquisition system. However, one of the significant features of the wind power industry is the diversity of equipment sources, and different manufacturers of wind turbine master PLCs often use different industrial communication protocols, such as Modbus, Profibus, Ethernet / IP, etc. This protocol diversity brings great challenges to the unified monitoring and operation of the wind farm, resulting in complex system integration, long development cycle and high maintenance cost.

[0003] In order to cope with the above challenges, some solutions have emerged, such as using multiple independent protocol gateways or developing special drivers for each protocol in the monitoring and data acquisition system. These solutions, although to some extent, solve the problem, but usually have many defects. On the one hand, using multiple hardware gateways will increase the physical complexity and failure points of the system, and the cost is high; on the other hand, developing and maintaining multiple protocol drivers at the software level not only requires a huge amount of work, but also requires modification, testing and redeployment of the existing system whenever a new type of PLC protocol is added, which seriously restricts the scalability and flexibility of the system. In addition, the traditional communication method often uses a point-by-point polling mechanism, that is, the monitoring and data acquisition system initiates an independent read-write request for each data point (such as wind speed, power, temperature, etc.) in the PLC. When the number of data points is large, this way will generate a large number of communication messages, greatly increasing the network load and the processing burden of the PLC, resulting in high data refresh delay and poor real-time performance, which cannot meet the requirements of modern wind farm fine operation for high timeliness of data.

[0004] Therefore, an optimized multi-protocol compatible wind power master PLC communication scheme is expected. SUMMARY

[0005] The embodiment of the present application aims to at least solve one of the technical problems existing in the prior art, and provides a multi-protocol compatible wind power master PLC communication method and system.

[0006] In a first aspect, embodiments of the present application provide a multi-protocol compatible wind power master control PLC communication method, comprising:

[0007] loading a protocol adaptation descriptor and parsing it to obtain a parsed PAD object;

[0008] performing dynamic communication adaptation and optimized request block generation on the parsed PAD object to obtain an optimized request block array and a response parsing mapping;

[0009] sending each optimized request block in the optimized request block array to a PLC device in sequence and receiving a response message from the PLC device to obtain an original response load array;

[0010] based on the response parsing mapping, performing data decoding and semantic conversion on the original response load array to obtain a semantic data set;

[0011] based on the point ID of each semantic data in the semantic data set, mapping it to a northbound interface model to obtain an OPC UA node update notification;

[0012] based on the publication mechanism of OPC UA, packaging the OPC UA node update notification into a secure data notification message and sending it to all subscribed SCADA clients.

[0013] In some possible embodiments, performing dynamic communication adaptation and optimized request block generation on the parsed PAD object to obtain an optimized request block array and a response parsing mapping comprises:

[0014] performing data point normalization and address footprint calculation on each original point in the data point list of the parsed PAD object to obtain a normalized point list;

[0015] performing continuous address block merging and optimization on the normalized point list to obtain a merged block list;

[0016] performing communication request block pre-compilation on the merged block list to obtain the optimized request block array;

[0017] performing response parsing mapping table generation on the merged block list to obtain the response parsing mapping.

[0018] In some possible embodiments, performing data point normalization and address footprint calculation on each original point in the data point list of the parsed PAD object to obtain a normalized point list comprises:

[0019] performing address resolution and conversion on the address of the original point to obtain digital address information;

[0020] calculating a register footprint of the raw point based on a size of each 16-bit register in a Modbus protocol and a data type of the raw point;

[0021] creating the raw point, the register footprint, and the digital address information as a normalized point object.

[0022] In some possible embodiments, performing continuous address block merging and optimization on the normalized point list to obtain a merged block list, including:

[0023] performing ascending order sorting on the normalized point list based on the digital address information to obtain a sorted point list;

[0024] traversing the sorted point list using a greedy algorithm to obtain the merged block list.

[0025] In some possible embodiments, traversing the sorted point list using a greedy algorithm to obtain the merged block list, including:

[0026] creating a current block for a first point in the sorted point list, the current block containing a start address and an initial total register number;

[0027] iterating a next point in the sorted point list, and performing the following operations on the next point: checking whether digital address information of the next point is equal to the start address of the current block plus the initial total register number; if yes, extending the current block such that a total register number of the current block is equal to the initial total register number plus a footprint register number of the next point; if no, storing the current block into the merged block list, and creating a next current block starting from the next point.

[0028] In some possible embodiments, performing communication request block pre-compilation on the merged block list to obtain an optimized request block array, including:

[0029] traversing each logical block in the merged block list, and generating a Modbus TCP PDU for the each logical block;

[0030] assembling the Modbus TCP PDU into a binary payload, and associating the binary payload with a block ID of the logical block to obtain a request object, wherein the optimized request block array is composed of a plurality of request objects.

[0031] In some possible embodiments, performing response parsing mapping table generation on the merged block list to obtain a response parsing mapping, including:

[0032] extracting a first logical block from the merged block list;

[0033] obtaining a block ID of the first logical block and taking the block ID of the first logical block as a key for parsing a response mapping;

[0034] traversing each inclusion point in an inclusion point list of the first logical block, calculating a byte offset of the inclusion point and creating a parsing rule object based on the byte offset;

[0035] associating the parsing rule object with the key for parsing the response to obtain a parsing rule in the response parsing mapping.

[0036] In a second aspect, an embodiment of the present application provides a multi-protocol compatible wind power master control PLC communication system, comprising:

[0037] a protocol adaptation descriptor parsing module, configured to load a protocol adaptation descriptor and parse the protocol adaptation descriptor to obtain a parsed PAD object;

[0038] a dynamic communication adaptation and request block generation module, configured to perform dynamic communication adaptation and optimized request block generation on the parsed PAD object to obtain an optimized request block array and a response parsing mapping;

[0039] a PLC processing module, configured to sequentially send each optimized request block in the optimized request block array to a PLC device and receive a response message from the PLC device to obtain an original response load array;

[0040] a data decoding and semantic conversion module, configured to perform data decoding and semantic conversion on the original response load array based on the response parsing mapping to obtain a semantic data set;

[0041] a mapping module, configured to map each semantic data in the semantic data set to a northbound interface model based on a point ID of the semantic data to obtain an OPC UA node update notification;

[0042] a data packaging and sending module, configured to package the OPC UA node update notification into a secure data notification message based on a publishing mechanism of OPC UA and send the secure data notification message to all subscribed SCADA clients.

[0043] In some possible embodiments, the dynamic communication adaptation and request block generation module is further configured to:

[0044] perform data point normalization and address footprint calculation on each original point in a data point list of the parsed PAD object to obtain a normalized point list;

[0045] perform continuous address block merging and optimization on the normalized point list to obtain a merged block list;

[0046] request block pre-compilation on the merged block list to obtain the optimized request block array;

[0047] response parsing mapping table generation on the merged block list to obtain the response parsing mapping.

[0048] In some possible embodiments, the dynamic communication adaptation and request block generation module is further used for:

[0049] address resolution and conversion on the address of the original point to obtain digital address information;

[0050] register footprint calculation of the original point based on the size of each 16-bit register in the Modbus protocol and the data type of the original point;

[0051] creation of the original point, the register footprint and the digital address information into a normalized point object.

[0052] Compared with the prior art, the multi-protocol compatible wind power master control PLC communication method and system provided by the embodiments of the present application introduce a protocol adaptation descriptor, describe the communication protocol, data point address and data type of a specific PLC in a unified structured manner. During system operation, the descriptor is first loaded and parsed, and is converted into an internal unified data model. Subsequently, through a dynamic communication adaptation and optimization engine, address footprint calculation, sorting and continuous address block merging are performed on the data points, and originally scattered and inefficient point-by-point requests are intelligently aggregated into the least number of block requests with the highest efficiency, thereby fundamentally solving the communication inefficiency and high delay problem caused by the traditional polling method. After interaction with the PLC, the system efficiently decodes and converts the original binary response message into a semanticized data set with explicit business meaning by using a pre-generated response parsing mapping. Thereafter, further extension is made to the upper layer integration, which seamlessly maps the point ID in the semanticized data to a standard northbound interface model (such as OPC UA) by using the point ID, and finally actively pushes data updates to all SCADA clients in a safe and efficient manner through the publish / subscribe mechanism of OPC UA. This way not only solves the pain points of communication message redundancy, high network load and large data delay in the traditional polling method, but also encapsulates the protocol details in the descriptor, realizes complete transparency to the upper layer application, and enables access to new PLC devices without modifying the core code, but only by configuring a new descriptor, thereby improving the compatibility, scalability and communication efficiency of the system. BRIEF DESCRIPTION OF DRAWINGS

[0053] In order to make the technical solutions of the embodiments of the present application or the prior art clearer, the accompanying drawings needed in the specific embodiments or prior art description will be briefly introduced. Obviously, the accompanying drawings in the following description are only some embodiments of the present application, and all other embodiments obtained by those of ordinary skill in the art without any creative work based on these accompanying drawings should fall into the protection scope of the present application.

[0054] Figure 1 Flow chart of the multi-protocol compatible wind power master control PLC communication method according to the embodiment of the present application;

[0055] Figure 2 Data flow diagram of the multi-protocol compatible wind power master control PLC communication method according to the embodiment of the present application;

[0056] Figure 3 Flow chart of the multi-protocol compatible wind power master control PLC communication method according to the embodiment of the present application, which performs dynamic communication adaptation and optimization request block generation on the parsed PAD object to obtain an optimized request block array and response parsing mapping;

[0057] Figure 4 Flow chart of the multi-protocol compatible wind power master control PLC communication method according to the embodiment of the present application, which performs continuous address block merging and optimization on the standardized point list to obtain a merged block list;

[0058] Figure 5 Block diagram of the multi-protocol compatible wind power master control PLC communication system according to the embodiment of the present application. DETAILED DESCRIPTION

[0059] In order to make the technical solutions of the embodiments of the present application or the prior art clearer, the accompanying drawings needed in the specific embodiments or prior art description will be briefly introduced. Obviously, the accompanying drawings in the following description are only some embodiments of the present application, and all other embodiments obtained by those of ordinary skill in the art without any creative work based on these accompanying drawings should fall into the protection scope of the present application.

[0060] Unless specifically defined otherwise, the technical terms or scientific terms used in the embodiments of the present application should be understood as the common meanings thereof by those of ordinary skill in the art to which the present application belongs. The "comprise" or "include" and the like used in the embodiments of the present application neither limit the mentioned shapes, numbers, steps, actions, operations, components, elements and / or their groups, nor exclude the presence or addition of one or more other different shapes, numbers, steps, actions, operations, components, elements and / or their groups, or addition of these.

[0061] The relative arrangement of parts and steps, numerical expressions, and values set forth in the examples illustrated herein are not intended to limit the scope of the application unless otherwise specifically stated. It is to be understood that the drawings are not necessarily drawn to scale and that the specific order and hierarchy of steps in methods that are shown are illustrative only and can generally be performed in other orders and heierarchy, including concurrently or in reversed order unless the context or the language specifically indicates otherwise. Any additional examples set forth in any of the examples are not to be taken as limiting unless otherwise specifically stated. It is noted that like symbols and labels are used to represent like elements throughout the several views.

[0062] In the description of embodiments of the present application, the description of the terms "one embodiment", "some embodiments”, "an example”, "a specific example” or "some examples” etc. means that the particular feature, structure, material or characteristic being described is included in at least one embodiment or example of the present application. The illustrative appearance of the above terms in various places in the description indicates that the particular feature, structure, material or characteristic is included in at least one embodiment or example of the present application. Moreover, the particular features, structures, materials or characteristics can be combined in any suitable manner in one or more embodiments or examples. Furthermore, the particular features, structures, materials or characteristics can be combined in any suitable manner in one or more embodiments or examples, without necessarily being combined in the same embodiment or example. In addition, those skilled in the art will appreciate that the various embodiments or examples described herein can be practiced with a variety of different systems and methods, and that the description of any specific embodiment or example does not limit the scope of the application.

[0063] Hereinafter, example embodiments according to the present application will be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are only a part of embodiments of the present application, and thus it should be understood that the present application is not limited to the described embodiments.

[0064] The current wind farm monitoring system is faced with some technical problems: the main control PLC of the field wind turbine has many brands, and the communication protocols such as Modbus and Profibus adopted by the main control PLC are different, which leads to extremely complex system integration, and the traditional point-by-point polling data acquisition method is low in efficiency, which seriously restricts the data real-time and system expansibility.

[0065] In the technical scheme of the present application, a multi-protocol compatible wind power master control PLC communication method is provided to solve the above technical problems, which starts with loading a protocol adaptation descriptor that can be flexibly configured, which accurately defines the protocol type, data point address, data format and other key information of the target PLC. Specifically, first, the protocol adaptation descriptor is parsed, and its content is converted into a standardized internal data structure. Then, address normalization and footprint calculation are performed on all data points, and strategies such as the greedy algorithm are used to intelligently merge addresses that are continuous or adjacent to each other into optimized data blocks. Based on these merged data blocks, the system pre-compiles a series of efficient batch request messages and synchronously creates an accurate response parsing mapping table. Subsequently, the system sends these optimized request messages to the PLC in one go and in order, and receives the returned response. Based on the pre-generated parsing mapping table, the system can quickly decode and convert the original binary data stream returned by the PLC and give it a clear business meaning to form a structured semantic data set. Finally, in order to realize seamless connection with the upper layer application, the system automatically maps these semantic data to the industry standard OPC UA information model according to their unique point ID, and uses the efficient publishing and subscribing mechanism of OPC UA to update the data as a standard notification and actively and safely push it to all subscribed SCADA monitoring clients, thereby building a highly automated, compatible and efficient data link from heterogeneous devices to the upper layer application.

[0066] In the technical scheme of the present application, a multi-protocol compatible wind power master control PLC communication method is provided. Figure 1 A flowchart of the multi-protocol compatible wind power master control PLC communication method according to the embodiment of the present application. Figure 2 A data flow schematic diagram of the multi-protocol compatible wind power master control PLC communication method according to the embodiment of the present application. Figure 1 and Figure 2As shown, the multi-protocol compatible wind power master control PLC communication method according to the embodiment of the application comprises the steps of: S100, loading a protocol adaptation descriptor and parsing the same to obtain a parsed PAD object; S200, generating a dynamic communication adaptation and optimization request block for the parsed PAD object to obtain an optimized request block array and a response parsing mapping; S300, sequentially sending each optimized request block in the optimized request block array to a PLC device and receiving a response message from the PLC device to obtain an original response load array; S400, based on the response parsing mapping, performing data decoding and semantic conversion on the original response load array to obtain a semantic data set; S500, based on the point ID of each semantic data in the semantic data set, mapping the semantic data to a northbound interface model to obtain an OPC UA node update notification; and S600, based on the publishing mechanism of OPC UA, packaging the OPC UA node update notification into a secure data notification message and sending the same to all subscribed SCADA clients.

[0067] Specifically, in step S100, a protocol adaptation descriptor is loaded and parsed to obtain a parsed PAD object. It should be understood that in the complex scenario of modern wind farm automation monitoring, due to the diversified communication protocols (such as Modbus TCP, Profibus-DP, IEC 61850, etc.) and private data point address mapping tables selected by different wind turbine manufacturers for their master PLCs, the upper monitoring system (SCADA) faces great challenges in integrating these heterogeneous devices. In order to solve this compatibility problem and avoid writing and maintaining independent, hard-coded drivers for each PLC, in the technical solution of the application, a protocol adaptation descriptor needs to be loaded and parsed to obtain a parsed PAD object. This can establish a unified, protocol-independent intermediate layer. By abstracting and encapsulating all details related to specific PLC communication (including protocol type, network endpoint, data point register address, data type, byte order, conversion coefficient, etc.) into an external, structured configuration file (i.e. protocol adaptation descriptor), the communication logic and protocol details are completely decoupled. Through this step, the purpose is to convert these heterogeneous, unstructured protocol information into standardized parsed PAD objects that can be understood and processed by the system internally. In this way, the flexibility and scalability of the system are greatly improved. When a new model or new manufacturer's PLC needs to be accessed, the technician does not need to modify or recompile the main program, but only needs to write and load a new protocol adaptation descriptor file, significantly shortening the integration period and reducing maintenance costs. Secondly, it provides a unified, standardized data basis for subsequent communication optimization (such as address block merging) and data parsing, and is the logical starting point and cornerstone of the entire multi-protocol compatible communication framework.

[0068] More specifically, in embodiments of the present application, the system reads a descriptor file in a predefined format upon startup or upon receiving a configuration update instruction. The file is in a common data serialization format such as JSON, XML or YAML, for ease of human readability and machine parsing. The implementation process can be summarized in the following stages. First, the system reads a JSON-formatted protocol adaptation descriptor file according to a pre-set path via a file I / O module, and the content of the file is loaded into memory as a string. Second, the system calls a JSON parser library (such as Newtonsoft.Json or System.Text.Json) to perform syntax checking and deserialization on the JSON string in memory. In this process, the parser will map the key-value pairs in the JSON to the corresponding fields of a pre-defined PAD data model class (a C# or Java object containing attributes such as protocol name, device IP, port, data point list, etc.) one by one. Each entry in the data point list contains detailed information such as point ID, register address, data type (e.g. float32, int16), read / write permissions, etc. Finally, when the deserialization is successfully completed, a structured parsed PAD object instance that is fully filled with data from the descriptor file is created in memory, and the object is then passed to the next processing unit of the system, namely the dynamic communication adaptation and optimization module, for subsequent use.

[0069] Specifically, in step S200, the parsed PAD object is subjected to dynamic communication adaptation and optimized request block generation to obtain an optimized request block array and a response parsing mapping. It should be understood that in the wind farm monitoring scenario, the SCADA system needs to collect hundreds or even thousands of data points from a single PLC, covering wind speed, power, temperature, voltage, equipment status, etc. If the traditional point-by-point polling method is used, i.e., an independent read-write request is initiated for each data point, a large number of fragmented messages will be generated in the communication network, greatly increasing the risk of network congestion and the CPU load of the PLC. This inefficient communication mode will cause the data refresh period to be too long, the critical alarm information to be delayed, and the high requirements of modern wind farms for data real-time and system response speed cannot be met. Therefore, in the technical solution of the present application, the parsed PAD object is further subjected to dynamic communication adaptation and optimized request block generation to obtain an optimized request block array and a response parsing mapping. In this way, a large number of discrete data point reading requests can be intelligently aggregated into the least number of batch communication tasks with the highest efficiency. The purpose is to dynamically generate a set of optimized communication request blocks by deeply analyzing and recombining all data points defined in the parsed PAD object, and to simultaneously build an accurate mapping table for decoding response data. This not only reduces the number of communication interactions, but also maximizes the data throughput of a single communication, thereby macroscopically improving the performance of the entire data acquisition link. That is, this enhances the dynamic adaptability of the system, regardless of how the data point list changes (addition, deletion, modification), the optimization process can automatically recalculate and generate the optimal communication strategy without human intervention. Finally, by generating an optimized request block array and a response parsing mapping matching the same, a solid foundation is laid for subsequent efficient and accurate data transmission and decoding.

[0070] Figure 3 For the multi-protocol compatible wind power master control PLC communication method according to the embodiment of the present application, the flowchart of the dynamic communication adaptation and optimized request block generation of the parsed PAD object to obtain the optimized request block array and the response parsing mapping. As shown in Figure 3 S200, it includes: S210, data point normalization and address footprint calculation are performed on each original point in the data point list of the parsed PAD object to obtain a normalized point list; S220, the normalized point list is subjected to continuous address block merging and optimization to obtain a merged block list; S230, the merged block list is subjected to communication request block pre-compilation to obtain the optimized request block array; S240, the merged block list is subjected to response parsing mapping table generation to obtain the response parsing mapping.

[0071] In step S210, data point normalization and address footprint calculation are performed on each original point in the data point list of the parsed PAD object to obtain a normalized point list. It should be understood that in the actual application scenario of wind farm monitoring, the original data point information parsed from the protocol adaptation descriptor (PAD) is often oriented towards human readability or follows specific vendor habits, rather than a machine-friendly format. For example, the address of the Modbus protocol is often represented in the form of a function area prefix (such as 4x, 3x) plus an offset (such as 40101), and different data types (such as 16-bit integers, 32-bit floating-point numbers, and 64-bit double-precision floating-point numbers) occupy different physical space sizes in the PLC memory. These original information has problems such as non-uniform format, non-numeric address, and unclear space occupation, and cannot be directly used for subsequent address sorting and continuity judgment. Therefore, in the technical solution of the present application, data point normalization and address footprint calculation are further performed on each original point in the data point list of the parsed PAD object to obtain a normalized point list. In this way, diversified and heterogeneous original data point definitions can be converted into a unified, quantized, and computer-friendly internal representation for logical operations and comparisons. That is, by converting all addresses into a unified digital format, address-based sorting and comparison operations become simple and efficient. By accurately calculating the register footprint of each data point, an accurate basis is provided for subsequent judgment of whether the address is continuous, ensuring the correctness of address block merging.

[0072] More specifically, in the embodiment of the present application, data point normalization and address footprint calculation are performed on each original point in the data point list of the parsed PAD object to obtain a normalized point list, including: address parsing and conversion of the address of the original point to obtain digital address information; based on the size of each 16-bit register in the Modbus protocol and the data type of the original point, calculating the register footprint of the original point; creating the original point, the register footprint, and the digital address information as a normalized point object.

[0073] Specifically, the process is executed by a data point preprocessing submodule. First, the submodule receives an original point object in the parsed PAD object as input, which may contain an address field "40101" and a data type field "float32". The first step of the module is to parse and convert the address, which will identify the function code prefix "4" in the address string and strip it according to the Modbus protocol specification, then convert the remaining "0101" to the decimal number 101, and subtract the offset base 1 to get the pure numerical address information 100. Secondly, the module calculates the register footprint based on the fact that each register in the Modbus protocol is 16 bits (2 bytes), and the data type of the original point is "float32". Since a 32-bit floating-point number needs to occupy two 16-bit registers, it is calculated that the register footprint of the point is 2. Finally, the submodule encapsulates and instantiates the original point object itself, the calculated numerical address information 100, and the register footprint 2 into a new normalized point object. This process is repeated for each original point in the data point list, and all generated normalized point objects are finally collected to form a complete normalized point list for use by the next stage of the continuous address block merging and optimization module.

[0074] In step S220, the normalized point list is merged and optimized for continuous address blocks to obtain a merged block list. It should be understood that in the wind farm monitoring scenario, after data point normalization processing, a list containing all the data points to be collected is obtained, each point having a clear numerical address and register footprint. However, these data points are still discrete and unordered individuals in the initial list. If a communication request is generated for each point, it will return to the inefficient point-by-point polling mode, which contradicts the original intention of optimization. PLC and communication protocols (such as Modbus) themselves support reading a continuous address area at a time, and the efficiency of batch reading is much higher than multiple separate readings. Therefore, the normalized point list is further merged and optimized for continuous address blocks to fully utilize the characteristics of the protocol and aggregate the originally dispersed requests. In this way, all physically continuous data points in the normalized point list can be identified and integrated, and they are logically bundled into one or more larger data blocks. This process aims to convert requests for multiple independent data points into requests for a few continuous address blocks, thereby minimizing the number of communication requests and maximizing the efficiency of single communication. The ultimate goal is to generate a merged block list, which is the direct basis for generating the final communication message and is the core output of the entire communication optimization strategy.

[0075] Figure 4A flow chart of the process of merging and optimizing the normalized point list to get the merged block list according to the multi-protocol compatible wind power master control PLC communication method of the embodiment of the present application. As shown in Figure 4 Step S220 includes: S221, sorting the normalized point list in ascending order based on the numerical address information to get a sorted point list; S222, traversing the sorted point list using a greedy algorithm to get the merged block list.

[0076] Specifically, the process is implemented by an address block optimizer module. First, the module receives the normalized point list generated in the previous stage as input. Based on the numerical address information of each normalized point object in the list, a standard sorting algorithm (such as quicksort or mergesort) is called to sort the entire list in ascending order, obtaining an address-ordered sorted point list.

[0077] Next, the module traverses the sorted point list using a greedy algorithm. In a specific example of the present application, the greedy algorithm traverses the sorted point list to get the merged block list, including: creating a current block for the first point in the sorted point list, the current block containing the starting address and the initial total number of registers; iterating the next point in the sorted point list and performing the following operations on the next point: checking whether the numerical address information of the next point is equal to the starting address of the current block plus the initial total number of registers; if so, extending the current block so that the total number of registers of the current block is equal to the initial total number of registers plus the footprint of the next point; if not, storing the current block in the merged block list and creating a next current block starting with the next point.

[0078] More specifically, when the algorithm is initialized, the first point in the list is taken as the starting point of the first current block, and its starting address and register footprint are recorded as the initial total number of registers of the current block. Then, the algorithm iteratively processes the next point in the list and performs a key judgment: checking whether the numerical address of the point is exactly equal to the starting address of the current block plus the total number of registers of the current block. If so, it means that the point seamlessly connects to the current block in terms of address, and the algorithm extends the current block by increasing its total number of registers by the register footprint of the point. If not, it means that the address has been interrupted, and the continuity of the current block ends at this point. At this time, the algorithm stores the current block, which has been constructed, in the final merged block list, and immediately creates a brand new current block starting with the newly encountered point. This iteration process continues until all sorted points are traversed, and the last current block is also stored in the list. Finally, the module outputs a merged block list, where each element represents an optimized continuous memory address block containing one or more original data points.

[0079] In step S230, the merged block list is precompiled into communication request blocks to obtain the optimized request block array. It should be understood that in the wind farm monitoring scenario, after the preceding address block merging and optimization steps, the system has successfully aggregated hundreds or thousands of discrete data point requests into a logical list containing multiple consecutive address blocks (i.e., the merged block list). However, this list itself is still an abstract, high-level plan that describes how data should be read, but is not a communication instruction that the PLC can directly recognize and execute. PLC devices, such as wind turbine controllers, only understand binary messages that follow specific protocol specifications (e.g., Modbus TCP). Therefore, the merged block list is further precompiled into communication request blocks to convert the high-level, logical data reading strategy into the underlying, specific, and directly network-transmissible physical communication instructions. For each optimized logical block, an executable request message that conforms to the target protocol standard is precisely constructed, aiming to translate each entry in the merged block list into a complete protocol data unit (PDU) containing all necessary protocol fields (such as function code, starting address, data length, etc.), and finally assembled into a binary payload array that can be directly sent to the PLC. This process is the bridge connecting the optimization strategy and the actual communication execution, ensuring that the optimization results can be effectively implemented.

[0080] Specifically, in the embodiments of the present application, the precompiling of the merged block list into communication request blocks to obtain the optimized request block array includes: traversing each logical block in the merged block list and generating a Modbus TCP PDU for each logical block; assembling the Modbus TCP PDU into a binary payload and associating it with the block ID of the logical block to obtain a request object, wherein the optimized request block array is composed of multiple request objects.

[0081] More specifically, the process is performed by a request compiler module. This module receives the list of merged blocks as input. First, it iterates through each logical block in the list. For a logical block, assume its protocol is Modbus TCP, its start address is 100, and its total register number is 10. The module generates a Modbus TCP protocol data unit (PDU) for this logical block according to the Modbus protocol specification. This involves setting the function code (e.g., 0x03 for reading holding registers), then encoding the logical block's start address (100) and total register number (10) as two bytes of big-endian integer, and concatenating these bytes to form the PDU. Next, the module assembles this generated PDU into the final binary payload. In the context of Modbus TCP, this also includes adding an MBAP header in front of the PDU, which contains the transaction identifier, protocol identifier, length, and unit identifier. This complete binary packet is the request message that can be sent directly. Finally, to facilitate management and subsequent response matching, the module associates this binary payload with the unique block ID of the logical block, creating a request object. By repeating this process for all logical blocks in the list of merged blocks, an optimized request block array consisting of multiple such request objects is finally generated, waiting to be sent by the communication scheduler.

[0082] In step S240, the response parsing mapping table is generated based on the merged block list to obtain the response parsing mapping. It should be understood that in the wind farm monitoring scenario, when the system sends an optimized batch read request to the PLC, a continuous stream of raw binary data will be received as a response. For example, a message requesting to read 10 consecutive registers will return a 20-byte binary payload. This binary payload itself does not contain any information about its internal data structure, and it is only a snapshot of memory. The system cannot directly know from it which bytes in the 20 bytes represent the generator speed, which bytes represent the gearbox oil temperature, and whether they are 16-bit integers or 32-bit floating-point numbers, and whether the byte order is big-endian or little-endian. Therefore, the response parsing mapping table generation step is performed to quickly and accurately restore the original binary response to meaningful and structured data when it is received. In this way, a detailed parsing rule can be created for each optimized request block. This process aims to establish a mapping relationship from the request identifier (block ID) to a set of specific parsing instructions. When a response is received, the system can quickly find the decoding guide through the corresponding request block ID, so as to know how to extract the value of each original data point from the returned binary data stream at the correct offset position, according to the correct data type and byte order. The ultimate goal is to generate an efficient and queryable response parsing mapping data structure, which is the key to realizing the conversion from the original message to the semantic data.

[0083] Specifically, in the embodiment of the application, the response parsing mapping table is generated based on the merged block list to obtain the response parsing mapping, including: extracting a first logical block from the merged block list; obtaining the block ID of the first logical block, and taking the block ID of the first logical block as the key of the response parsing mapping; traversing each containing point in the containing point list of the first logical block, calculating the byte offset of the containing point and creating a parsing rule object based on the byte offset; and associating the parsing rule object with the key of the response parsing mapping to obtain a parsing rule in the response parsing mapping.

[0084] That is, in one specific example of the present application, the process is performed in parallel with the request block pre-compilation, and is responsible for a parsing mapping generator module. The module also receives the merged block list as input. First, it extracts the first logical block from the list and obtains its unique block ID, such as "Block_001". This block ID will be used as the key in the response parsing mapping table (usually a hash table or dictionary structure). Then, the module begins to traverse the list of original data points contained in this logical block. For the first point in the list, assuming its data type is int16 (occupying 2 bytes), the module calculates its byte offset as 0. For the second point, assuming its data type is float32 (occupying 4 bytes), the module calculates its byte offset as 2 (immediately after the first point). For the third point, assuming its data type is int16, its byte offset is then 6 (2+4). For each containing point, the module creates a parsing rule object containing the unique ID of the point, the calculated byte offset, the data type (float32), the byte order (such as Big-Endian), and all the information required for decoding. Finally, the module associates the set of parsing rule objects generated for all points in this logical block with the key "Block_001" and stores it in the response parsing mapping table, forming a complete parsing rule. This process is repeated for each logical block in the merged block list, and a complete response parsing mapping is finally generated, fully preparing for the subsequent data decoding and semantic conversion stage.

[0085] Specifically, in step S300, each optimized request block in the optimized request block array is sent to the PLC device in order, and a response message from the PLC device is received to obtain an original response load array. It should be understood that in the actual operation scenario of wind farm monitoring, all preparatory work including parsing protocol descriptors, optimizing request blocks, and generating parsing mappings must ultimately be translated into actual communication interactions with the on-site PLC device, otherwise the data cannot be obtained. The system has carefully prepared the optimized request block array, and now these optimized request block arrays must be input to the PLC device and accept the response information. Therefore, in the technical solution of the present application, each optimized request block in the optimized request block array is further sent to the PLC device in order, and a response message from the PLC device is received to obtain an original response load array. The highly optimized data request strategy is implemented, a connection with the target PLC is established through the network, and a data reading operation is accurately performed, and finally the original data returned by the PLC is safely and completely retrieved, aiming to complete a complete request-response communication cycle, and to convert the pre-compiled binary request block into a real, unprocessed data snapshot in the PLC memory, i.e. the original response load array.

[0086] More specifically, in one specific example of the application, the process is handled by a communication scheduler module. This module runs in a separate execution thread with a fixed periodicity (e.g. once per second). At the beginning of a collection cycle, the scheduler takes the first request object from the array of optimized request blocks in sequence. This object contains the IP address, port number of the target PLC, and the precompiled binary request message. The scheduler establishes a TCP connection to the specified IP and port of the target PLC through the socket API provided by the operating system. After the connection is successful, it writes the binary message in the request object into the connection through a network stream. After the sending is completed, the scheduler waits for the response data from the TCP connection synchronously or asynchronously. It continuously reads bytes from the network stream until a complete response message is received, which is in accordance with the protocol specification (e.g. the length field in the MBAP header of the Modbus TCP response message). The part of binary data received, is the original response payload corresponding to the first request block. The scheduler associates this payload with the block ID used in the request, and stores it in a temporary array of original response payloads. Subsequently, the scheduler continues to process the next request object in the array of request blocks, repeating the sending and receiving process described above, until all optimized request blocks have been sent and responses have been received. Finally, the module passes the array of complete original response payloads collected, corresponding to the request blocks, to the data decoding and semantic conversion module for further processing.

[0087] Specifically, in step S400, the original response payload array is data decoded and semantized based on the response parsing mapping to obtain a semantized dataset. It should be appreciated that in the wind farm monitoring scenario, the system has already acquired the original response payload array from the PLC through the communication execution phase. Each element in this array is a long string of original, indiscriminate binary byte stream, which is a direct mirror of the PLC memory area. Such binary data is completely incomprehensible and unusable for the upper SCADA application or data analysis system. They do not know which bytes in this byte stream represent wind speed and which bytes represent grid frequency, nor do they know how to combine and convert these bytes into numerical values with actual physical units (such as m / s or Hz). Therefore, the original response payload array is further data decoded and semantized based on the response parsing mapping to translate machine-level, meaningless binary data into information that humans and upper applications can understand and have clear business meaning. Specifically, the original response payload is precisely reverse-engineered using the pre-constructed response parsing mapping table, aiming to disassemble, convert and give each binary response its business-level meaning according to its corresponding parsing rule. Specifically, it is to extract the value of each independent data point from the binary stream and convert it from the original register representation (such as 16-bit integer) to its real physical quantity representation (such as floating-point number with decimal), while adding its unique identifier (point ID) and timestamp. The ultimate goal is to generate a structured, human-readable and machine-easy-to-process semantized dataset. The generated semantized dataset is the final effective output of the entire data acquisition link, the data cornerstone driving the monitoring screen update, alarm judgment, historical trend recording and advanced algorithm analysis, and the core link to realize the value of the entire system.

[0088] More specifically, in one specific example of the present application, the process is performed by a data decoder module. The module receives the array of raw response payloads and the response resolution mapping table as inputs. First, it iterates through the array of raw response payloads, taking out the first raw response payload and its associated block ID, e.g. Block_001. Then, it uses this block ID as a key to look up the corresponding resolution rule set in the response resolution mapping table. Having found the rule set, the module starts iterating through each resolution rule in it. Suppose the first rule indicates: point ID Genspeed, byte offset 0, data type float32, byte order Big-Endian. The decoder will then start reading 4 bytes from the 0th byte of the raw response payload corresponding to Block_001. Next, it will order the 4 bytes according to the rule of Big-Endian, and call a standard library function (e.g. BitConverter.ToSingle) to convert the binary sequence of the 4 bytes into a 32-bit float, e.g. 1500.5. The module then creates a semantic data object, and stores the point ID Genspeed, the converted value 1500.5, and the current timestamp in the object. The decoder will continue processing the next rule in the rule set, e.g. point ID OilTemp, byte offset 4, data type int16, and it will start reading 2 bytes from the 4th byte of the payload, and convert it into a 16-bit integer. By repeating this operation for all rules in the rule set, and collecting all generated semantic data objects, the decoding of this response payload is completed. This process is applied to all elements in the array of raw response payloads, and finally all generated semantic data objects are aggregated to form a complete semantic data set, which can be directly used by the upper layer application.

[0089] Specifically, in step S500, based on the point ID of each semantic data in the semantic data set, it is mapped to a northbound interface model to obtain an OPC UA node update notification. It should be understood that after decoding and semantic conversion, a semantic data set containing accurate numerical values and business identifiers (point ID) has been obtained. However, this data set is a private data structure within the communication system, and its format and access method is unknown and incompatible to the outside world, especially to the upper SCARDA system, historical database or cloud analysis platform and other client applications. These upper applications usually follow industry standard interfaces (such as OPC UA) for data interaction. Therefore, it is necessary to bridge the gap between internal data representation and industry standard interface, and translate the semantic data set into a common and standardized language, so that it can be recognized and used by a wide range of industrial ecosystems. Based on this, in the technical solution of the present application, based on the point ID of each semantic data in the semantic data set, it is mapped to a northbound interface model to obtain an OPC UA node update notification. In this way, a standardized data publishing outlet can be constructed to seamlessly connect the internal collected data with business meaning to a public and standardized OPC UA information model. That is, using the point ID in the semantic data as a unique connection key, the corresponding node is found or created in the OPC UA server address space of the system, and the value, state and timestamp of the node are updated to the latest information carried by the semantic data. The ultimate goal is to generate a series of OPC UA node update notifications, which are the official records of the internal data state changes of the OPC UA server and the premise of triggering the subsequent data publishing mechanism.

[0090] More specifically, in one specific example of the present application, this process is taken care of by an OPC UA mapping and service module. This module, upon system initialization, constructs the address space of an OPC UA server based on the configuration or industry information model (e.g. IEC 61400-25). This address space contains nodes representing various components and parameters of the wind turbine, and each node has a clear correspondence with the point IDs defined in the protocol adaptation descriptor (either through its NodeId or a custom attribute). When this module receives the semanticized dataset generated in the previous stage, it iterates through each semanticized data object. For example, it takes out a data object containing point ID: Genspeed and value 1500.5. The module uses the point ID Genspeed to look up in a mapping table (e.g. a dictionary from point ID to OPC UA NodeId) it maintains internally, and finds the corresponding OPC UA node, e.g. the node with NodeId ns=2; s=Fanuc.Robot.Genspeed. Subsequently, the module calls the internal API of the OPC UA server to create a DataChangeNotification containing the NodeId of the target node, the new value (a Variant object encapsulating 1500.5), the status code (Good), and the source timestamp. This notification is submitted to the internal event queue of the OPC UA server. By repeating this mapping and updating process for all data objects in the semanticized dataset, the module generates corresponding OPC UA node update notifications for all data points that have changed, and these notifications mark that the internal data of the server has been refreshed and is ready to be pushed to clients through the publishing mechanism.

[0091] Specifically, in step S600, based on the OPC UA publishing mechanism, the OPC UA node update notification is packaged into a secure data notification message and sent to all subscribed SCADA clients. It should be understood that in the overall architecture of the wind farm monitoring, the data has successfully updated the address space of the internal OPC UA server after being collected, optimized, decoded and standardized mapped from the field PLC. However, these updated data only stay on the server side, and the remote SCADA monitoring client, engineer station or cloud platform are unaware of the changes. If relying on the client to actively and frequently poll the server to obtain data, not only will it degenerate into an inefficient communication mode, increasing network burden, but also cannot guarantee the timeliness of data update. Therefore, the data pushing step based on the OPC UA publishing mechanism is performed to notify the server-side data changes to all clients concerned about the data in real time and securely. By utilizing the mature Publish-Subscribe model in the OPC UA standard, the node update notification generated inside the server is actively, batchly and securely distributed to all SCADA clients that have established a subscription relationship. This step aims to change passive query to active push, ensuring that all related clients can receive notifications in the first time once the server data changes, thereby realizing data synchronization between the server and the client. In this way, the delay and efficiency problems brought by the traditional polling mode are solved, ensuring the real-time refresh of the SCADA client screen and the immediate response of the alarm. The built-in security mechanism of OPC UA (such as encryption and signature) ensures the confidentiality and integrity of the data in the transmission process, meeting the high requirements of industrial control systems for network security. In addition, the Publish-Subscribe model naturally supports one-to-many communication, and when the number of monitoring clients increases, the load on the server side will not increase linearly, showing excellent scalability.

[0092] More specifically, in one specific example of the present application, the process is automatically performed by the subscription and publication engine of the OPC UA server. Before this, one or more SCADA clients have established a secure session with the server of the present system through the OPC UA protocol, and created one or more subscriptions. When creating a subscription, the client specifies a publication interval (e.g. 1000 milliseconds), and creates multiple monitored items (MonitoredItems) under this subscription, each corresponding to an OPC UA node (e.g. a Genspeed node) that it is interested in. When the mapping module of the previous stage generates OPC UA node update notifications, these notifications are sent into the internal event queue of the server. The subscription and publication engine continuously monitors this queue. When a publication period arrives (e.g. 1000 milliseconds have passed since the last publication), the engine checks all active subscriptions. For a certain subscription, the engine collects all update notifications generated by all monitored item nodes under this subscription since the last publication. Then, the engine packages these collected node update notifications into one or more data notification messages. According to the security policy negotiated when the client session was established, this message is serialized, and possibly encrypted and digitally signed, to form a secure data package. Finally, the server sends this packaged and encrypted data notification message to the corresponding SCADA client through the established secure channel. After receiving the message, the client decrypts and verifies the signature, and then parses out the individual node updates contained in the message, and refreshes its interface display or triggers corresponding business logic accordingly.

[0093] In summary, the multi-protocol compatible wind power master control PLC communication method according to the embodiment of the present application is illustrated, which introduces a protocol adaptation descriptor to describe the communication protocol, data point address and data type of a specific PLC in a unified structured manner. During system operation, the descriptor is first loaded and parsed to be converted into an internal unified data model. Subsequently, through a dynamic communication adaptation and optimization engine, address footprint calculation, sorting and continuous address block merging are performed on the data points, and originally scattered and inefficient point-by-point requests are intelligently aggregated into block requests with the least number and the highest efficiency, thereby fundamentally solving the communication inefficiency and high delay problem caused by the traditional polling method. After interaction with the PLC, the system utilizes a pre-generated response parsing mapping to efficiently decode and convert the original binary response message into a semantic data set with clear business meaning. Thereafter, further extension is made to the upper layer integration, which utilizes the point ID in the semantic data to seamlessly map to a standard northbound interface model (such as OPC UA), and finally updates the data to all SCADA clients in a safe and efficient manner through the publish / subscribe mechanism of OPC UA. This method not only solves the problems of communication message redundancy, high network load and large data delay in the traditional polling method, but also realizes complete transparency to the upper layer application by encapsulating the protocol details in the descriptor, so that access to new PLC devices does not require modification of the core code, but only needs to configure a new descriptor, thereby improving the compatibility, scalability and communication efficiency of the system.

[0094] Further, a multi-protocol compatible wind power master control PLC communication system is also provided.

[0095] Figure 5 A block diagram of the multi-protocol compatible wind power master control PLC communication system according to the embodiment of the present application is shown in FIG. 1. As shown in FIG. 1, the system comprises a protocol adaptation descriptor 101, a dynamic communication adaptation and optimization engine 102, a PLC communication module 103, a response parsing and decoding engine 104, a semantic data set 105, a northbound interface model 106 and an OPC UA publish / subscribe mechanism 107. Figure 5As shown, the multi-protocol compatible wind power master control PLC communication system 100 according to the embodiment of the application comprises: a protocol adaptation descriptor parsing module 110, configured to load a protocol adaptation descriptor and parse the protocol adaptation descriptor to obtain a parsed PAD object; a dynamic communication adaptation and request block generation module 120, configured to perform dynamic communication adaptation and optimized request block generation on the parsed PAD object to obtain an optimized request block array and a response parsing mapping; a PLC processing module 130, configured to sequentially send each optimized request block in the optimized request block array to a PLC device and receive a response message from the PLC device to obtain an original response load array; a data decoding and semantic conversion module 140, configured to perform data decoding and semantic conversion on the original response load array based on the response parsing mapping to obtain a semantic data set; a mapping module 150, configured to map each semantic data in the semantic data set to a northbound interface model based on a point ID of the semantic data to obtain an OPC UA node update notification; and a data packaging and sending module 160, configured to package the OPC UA node update notification into a secure data notification message based on a publishing mechanism of OPC UA and send the secure data notification message to all subscribed SCADA clients.

[0096] Further, the dynamic communication adaptation and request block generation module 120 is specifically further configured to: perform data point normalization and address footprint calculation on each original point in a data point list of the parsed PAD object to obtain a normalized point list; perform continuous address block merging and optimization on the normalized point list to obtain a merged block list; perform communication request block pre-compilation on the merged block list to obtain the optimized request block array; and perform response parsing mapping table generation on the merged block list to obtain the response parsing mapping.

[0097] Further, the dynamic communication adaptation and request block generation module 120 is specifically further configured to: perform address resolution and conversion on an address of the original point to obtain digital address information; calculate a register footprint of the original point based on a size of each 16-bit register in the Modbus protocol and a data type of the original point; and create the original point, the register footprint and the digital address information as a normalized point object.

[0098] As mentioned above, the multi-protocol compatible wind master control PLC communication system 100 according to the embodiments of the present application can be implemented in various wireless terminals, such as a server with the multi-protocol compatible wind master control PLC communication algorithm, etc. In one possible implementation, the multi-protocol compatible wind master control PLC communication system 100 according to the embodiments of the present application can be integrated into a wireless terminal as a software module and / or a hardware module. For example, the multi-protocol compatible wind master control PLC communication system 100 can be a software module in the operating system of the wireless terminal, or can be an application program developed for the wireless terminal; of course, the multi-protocol compatible wind master control PLC communication system 100 can also be one of the hardware modules of the wireless terminal.

[0099] It can be understood that the above embodiments are only exemplary embodiments adopted for illustrating the principles of the present application, and the present application is not limited thereto. Various modifications and improvements can be made by those of ordinary skill in the art without departing from the spirit and essence of the present application, and these modifications and improvements are also considered to be within the protection scope of the present application.

Claims

1. A multi-protocol compatible wind power main control PLC communication method, characterized in that, include: Load the protocol adapter descriptor and parse it to obtain the parsed PAD object; Dynamic communication adaptation and optimization request block generation are performed on the parsed PAD object to obtain an optimized request block array and response parsing mapping; The optimized request blocks in the optimized request block array are sent to the PLC device in sequence, and the response messages from the PLC device are received to obtain the original response load array. Based on the response parsing mapping, the original response payload array is decoded and semantically transformed to obtain a semantic dataset. Based on the point IDs of each semantic data in the semantic dataset, they are mapped to the northbound interface model to obtain OPC UA node update notifications; Based on the OPC UA publishing mechanism, the OPC UA node update notifications are packaged into secure data notification messages and sent to all subscribed SCADA clients.

2. The multi-protocol compatible wind power main control PLC communication method according to claim 1, characterized in that, Dynamic communication adaptation and optimization of request block generation are performed on the parsed PAD object to obtain an optimized request block array and response parsing mapping, including: Data point normalization and address footprint calculation are performed on each original point in the data point list of the parsed PAD object to obtain a normalized point list; The normalized point list is then merged and optimized to obtain a merged block list. The merged block list is pre-compiled with communication request blocks to obtain the optimized request block array; A response parsing mapping table is generated from the merged block list to obtain the response parsing mapping.

3. The multi-protocol compatible wind power main control PLC communication method according to claim 2, characterized in that, The data point list of the parsed PAD object is normalized and its address footprint is calculated to obtain a normalized point list, including: The address of the original point is parsed and converted to obtain digital address information; Calculate the register footprint of the original point based on the size of each 16-bit register in the Modbus protocol and the data type of the original point. The original point, the register footprint, and the digital address information are created as normalized point objects.

4. The multi-protocol compatible wind power main control PLC communication method according to claim 3, characterized in that, The normalized point list is subjected to contiguous address block merging and optimization to obtain a merged block list, including: Based on the digital address information, the normalized point list is sorted in ascending order to obtain a sorted point list; A greedy algorithm is used to traverse the sorted list of points to obtain the merged block list.

5. The multi-protocol compatible wind power main control PLC communication method according to claim 4, characterized in that, A greedy algorithm is used to traverse the sorted list of points to obtain the merged block list, including: Create a current block for the first point in the sorted point list, the current block containing the starting address and the initial total number of registers; Iterate through the next point in the sorted point list and perform the following operations on the next point: check whether the digital address information of the next point is equal to the starting address of the current block plus the initial total number of registers; if so, expand the current block so that the total number of registers in the current block is equal to the initial total number of registers plus the placeholder registers of the next point; if not, store the current block in the merged block list and create the next current block starting from the next point.

6. The multi-protocol compatible wind power main control PLC communication method according to claim 5, characterized in that, The merged block list is pre-compiled with communication request blocks to obtain the optimized request block array, including: Iterate through each logical block in the merged block list and generate a Modbus TCP PDU for each logical block; The Modbus TCP PDU is assembled into a binary payload and associated with the block ID of the logical block to obtain the request object, wherein the optimized request block array consists of multiple request objects.

7. The multi-protocol compatible wind power main control PLC communication method according to claim 5, characterized in that, The response parsing mapping is obtained by generating a response parsing mapping table from the merged block list, including: Extract the first logical block from the merged block list; Obtain the block ID of the first logical block, and use the block ID of the first logical block as the key for the response parsing mapping; Iterate through each containing point in the containing point list of the first logic block, calculate the byte offset of the containing point, and create a parsing rule object based on the byte offset; The parsing rule object is associated with the key of the response parsing map to obtain a parsing rule in the response parsing map.

8. A multi-protocol compatible wind power main control PLC communication system, characterized in that, include: The protocol adapter descriptor parsing module is used to load the protocol adapter descriptor and parse it to obtain the parsed PAD object; The dynamic communication adaptation and request block generation module is used to perform dynamic communication adaptation and optimized request block generation on the parsed PAD object to obtain an optimized request block array and response parsing mapping; The PLC processing module is used to send each optimized request block in the optimized request block array to the PLC device in sequence, and to receive response messages from the PLC device to obtain the original response load array. The data decoding and semantic transformation module is used to perform data decoding and semantic transformation on the original response payload array based on the response parsing mapping to obtain a semantic dataset; The mapping module is used to map the point IDs of each semantic data point in the semantic dataset to the northbound interface model to obtain OPC UA node update notifications. The data packaging and sending module is used to package the OPC UA node update notifications into secure data notification messages and send them to all subscribed SCADA clients based on the OPC UA publishing mechanism.

9. The multi-protocol compatible wind power main control PLC communication system according to claim 8, characterized in that, The dynamic communication adaptation and request block generation module is also specifically used for: Data point normalization and address footprint calculation are performed on each original point in the data point list of the parsed PAD object to obtain a normalized point list; The normalized point list is then merged and optimized to obtain a merged block list. The merged block list is pre-compiled with communication request blocks to obtain the optimized request block array; A response parsing mapping table is generated from the merged block list to obtain the response parsing mapping.

10. The multi-protocol compatible wind power main control PLC communication system according to claim 9, characterized in that, The dynamic communication adaptation and request block generation module is also specifically used for: The address of the original point is parsed and converted to obtain digital address information; Calculate the register footprint of the original point based on the size of each 16-bit register in the Modbus protocol and the data type of the original point. The original point, the register footprint, and the digital address information are created as normalized point objects.

Images