Inverter identification methods, devices, electronic equipment, storage media and products

Abstract

This application discloses an inverter identification method, apparatus, electronic device, storage medium, and product. The method, applied to a data acquisition device, includes: traversing a local feature library to attempt to send a request frame to a target inverter for each inverter model in the local feature library, according to the corresponding protocol information; if the response frame returned by the target inverter matches the protocol information of the currently attempted inverter model, then the model and station number of the target inverter are determined, and the traversal stops; if the response frame returned by the target inverter does not match the protocol information of any inverter model in the local feature library, then the response frame is reported to a server to request the server to match the protocol information in a cloud-based feature library. This scheme first attempts to identify the target inverter by traversing the local feature library; if identification fails, it can also report to a server so that the server can match the corresponding protocol information in a more comprehensive cloud-based feature library, thus achieving automatic inverter identification and protocol adaptation.

Description

Technical Field

[0001] This application relates to the field of power communication technology, and in particular to an inverter identification method, device, electronic device, storage medium and product. Background Technology

[0002] In the operation, maintenance, and testing of distributed photovoltaic power plants, acquiring inverter operating data (such as voltage, current, and power generation) is crucial. Inverters from different manufacturers, and even different models from the same manufacturer, typically differ in their Modbus communication protocols regarding slave addresses (station numbers), data register addresses, and data formats. Currently, data acquisition equipment usually embeds the protocol information for specific inverter models into its local program. This presents several problems, including: poor adaptability: encountering a new inverter requires on-site personnel to find the station number and address through trial and error, sometimes even requiring code modifications—a tedious, inefficient, and potentially dangerous process; difficult maintenance: when inverter firmware upgrades lead to protocol changes, the data acquisition equipment cannot adapt, requiring on-site firmware updates, resulting in high maintenance costs; and inability to handle unknown devices: the acquisition equipment is completely inoperable for new inverters not included in the database.

[0003] In some scenarios, data acquisition devices can request configuration information for specific inverter models from the centralized control platform, thereby achieving compatibility with different inverters. While this method addresses some issues related to protocol rigidity, it remains essentially a passive configuration method: the acquisition device must know the exact inverter model in advance and use this information to request configuration information from the platform. However, in actual engineering projects, on-site maintenance personnel may not be able to obtain or confirm the exact inverter model, thus limiting the application of this method.

[0004] In summary, how to identify and obtain the protocol configuration of an inverter with an unknown model is an urgent problem to be solved. Summary of the Invention

[0005] This application provides an inverter identification method, device, electronic device, storage medium, and product to achieve automatic identification and protocol adaptation of unknown inverters.

[0006] In a first aspect, embodiments of this application provide an inverter identification method, applied to a data acquisition device, comprising: Traverse the local feature library to attempt to send a request frame to the target inverter for each inverter model in the local feature library according to the corresponding protocol information of the inverter model. The local feature library contains a first number of known inverter models corresponding to protocol information. The request frame is used to request to read the parameters of the target inverter related to the protocol information. If the response frame returned by the target inverter matches the protocol information of the currently attempted inverter model, then the model of the target inverter is determined to be the currently attempted inverter model, the station number of the target inverter is determined, and the traversal stops. If the response frame returned by the target inverter does not match the protocol information of each inverter model in the local feature library, the response frame is reported to the server to request the server to match the protocol information of the response frame in the cloud feature library. The cloud feature library contains a second number of known inverter models corresponding to protocol information, the second number being greater than the first number. The protocol information includes model identifier and station number range.

[0007] Secondly, embodiments of this application also provide an inverter identification method, applied to a server, comprising: The system receives a response frame reported by a data acquisition device. The response frame is reported by the data acquisition device when the response frame does not match the protocol information of each inverter model in the local feature library. The local feature library contains protocol information corresponding to a first number of known inverter models. According to the response frame, the protocol information of the response frame is matched in the cloud feature library. The cloud feature library contains a second number of known inverter models corresponding to protocol information, the second number being greater than the first number. The protocol information includes model identifier and station number range. The protocol information matching the response frame is sent to the data acquisition device.

[0008] Thirdly, embodiments of this application also provide an inverter identification device, including: The traversal module is used to traverse the local feature library to attempt to send a request frame to the target inverter for each inverter model in the local feature library according to the corresponding protocol information of the inverter model. The local feature library contains a first number of known inverter models corresponding to protocol information. The request frame is used to request to read the parameters of the target inverter related to the protocol information. The identification module is used to determine the model of the target inverter as the currently attempted inverter model and determine the station number of the target inverter if the response frame returned by the target inverter matches the protocol information of the currently attempted inverter model, and then stop traversing. The reporting module is used to report the response frame to the server if the response frame returned by the target inverter does not match the protocol information of each inverter model in the local feature library, so as to request the server to match the protocol information of the response frame in the cloud feature library. The cloud feature library contains a second number of known inverter models corresponding to protocol information, the second number being greater than the first number. The protocol information includes model identifier and station number range.

[0009] Fourthly, embodiments of this application also provide an inverter identification device, including: The receiving module is used to receive response frames reported by the data acquisition device. The response frames are reported by the data acquisition device when the response frames do not match the protocol information of each inverter model in the local feature library. The local feature library contains protocol information corresponding to a first number of known inverter models. The matching module is used to match the protocol information of the response frame in a cloud feature library based on the response frame. The cloud feature library contains a second number of known inverter models corresponding to protocol information, the second number being greater than the first number. The protocol information includes model identifiers and station number ranges. The sending module is used to send protocol information matching the response frame to the data acquisition device.

[0010] Fifthly, embodiments of this application provide a data acquisition device, including: One or more processors; Storage device for storing one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the inverter identification method as described in the first aspect.

[0011] Sixthly, embodiments of this application provide a server, including: One or more processors; Storage device for storing one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the inverter identification method as described in the second aspect.

[0012] In a seventh aspect, embodiments of this application also provide an inverter identification system, including: a data acquisition device as described in the fifth aspect, and a server as described in the sixth aspect.

[0013] Eighthly, embodiments of this application also provide a computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the inverter identification method as described in the first aspect.

[0014] This application provides an inverter identification method, apparatus, electronic device, storage medium, and product. The inverter identification method is applied to a data acquisition device and includes: traversing a local feature library to attempt to send a request frame to a target inverter for each inverter model in the local feature library according to the corresponding protocol information of the inverter model. The local feature library contains a first number of known inverter models corresponding to protocol information, and the request frame is used to request to read parameters related to the protocol information of the target inverter; if the response frame returned by the target inverter matches the protocol information of the currently attempted inverter model, the model of the target inverter is determined as the currently attempted inverter model, the station number of the target inverter is determined, and the traversal stops; if the response frame returned by the target inverter does not match the protocol information of each inverter model in the local feature library, the response frame is reported to a server to request the server to match the protocol information of the response frame in a cloud feature library. The cloud feature library contains a second number of known inverter models corresponding to protocol information, the second number being greater than the first number, and the protocol information includes a model identifier and a station number range. The above technical solution first attempts to identify the target inverter by traversing the local feature library. If the identification fails, it can be reported to the server so that the server can match the corresponding protocol information in a more comprehensive cloud feature library, thereby realizing automatic identification and protocol adaptation of the inverter. Attached Figure Description

[0015] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale.

[0016] Figure 1 A flowchart illustrating an inverter identification method provided in this application embodiment; Figure 2 A schematic diagram illustrating the process of a data acquisition device actively traversing a local feature database, as provided in an embodiment of this application; Figure 3 A schematic diagram of a data acquisition architecture provided in one embodiment; Figure 4 A flowchart illustrating another inverter identification method provided in this application embodiment; Figure 5 A flowchart illustrating an inverter identification process provided in an embodiment of this application; Figure 6This is a schematic diagram of the structure of an inverter identification device provided in an embodiment of this application; Figure 7 A schematic diagram of another inverter identification device provided in this application embodiment; Figure 8 This is a schematic diagram of the structure of a data acquisition device provided in an embodiment of this application; Figure 9 This application provides a schematic diagram of the structure of a server according to an embodiment of the present application. Figure 10 This is a schematic diagram of the structure of an inverter identification system provided in an embodiment of this application. Detailed Implementation

[0017] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the present application and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the present application are shown in the drawings, not all structures. Moreover, unless otherwise specified, the embodiments and features described in the present application can be combined with each other.

[0018] Before discussing the exemplary embodiments in more detail, it should be noted that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although the flowcharts describe the steps as sequential processes, many of these steps can be performed in parallel, concurrently, or simultaneously. Furthermore, the order of the steps can be rearranged. The process can be terminated when its operation is complete, but may also have additional steps not included in the figures. The process can correspond to a method, function, procedure, subroutine, subroutine, etc.

[0019] It should be noted that the concepts of "first" and "second" mentioned in the embodiments of this application are only used to distinguish different devices, modules, units or other objects, and are not used to limit the order of functions performed by these devices, modules, units or other objects or their interdependencies.

[0020] In the embodiments of this application, "multiple" refers to at least two unless otherwise specified.

[0021] In the embodiments of this application, "A / B" refers to A and / or B unless otherwise specified.

[0022] The acquisition, storage, use, and processing of data in this application all comply with the relevant provisions of national laws and regulations.

[0023] In the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, they do not mean that the applicant has used or necessarily used the relevant content of the solution.

[0024] Figure 1 This flowchart illustrates an inverter identification method provided in this application embodiment. This embodiment is applicable to situations involving the identification of unknown inverters, and can be used in photovoltaic power plant monitoring and industrial automation data acquisition scenarios, particularly distributed photovoltaic power plants. Its aim is to enable data acquisition equipment to adaptively identify inverters of different manufacturers and models and complete protocol adaptation and data acquisition. Specifically, this inverter identification method can be executed by an inverter identification device, which can be implemented through software and / or hardware and integrated into the data acquisition equipment. The data acquisition equipment includes, but is not limited to, computers, data loggers, or industrial IoT gateways.

[0025] like Figure 1 As shown, the method specifically includes the following steps: S110. Traverse the local feature library. For each inverter model in the local feature library, attempt to send a request frame to the target inverter according to the corresponding protocol information of the inverter model.

[0026] In this embodiment, the local feature library can be used to store protocol information of various models of inverters from different manufacturers.

[0027] For example, the local feature library contains protocol information corresponding to a first number of known inverter models. The protocol information includes the inverter's model identifier and station number range, and optionally, may also include manufacturer information and / or data frame structure characteristics. The request frame is used to request the reading of parameters related to the protocol information of the target inverter.

[0028] The target inverter can be understood as an inverter of unknown model, i.e., the inverter to be identified. When the data acquisition device cannot successfully establish communication with the target inverter, it can enter the inverter identification process, start the local active traversal mode, traverse the local feature library, and attempt to send request frames to the target inverter using various protocol information stored in the local feature library in turn. Based on the response frame returned by the target inverter (which includes parameters related to the protocol information), it can be determined whether the target inverter matches the protocol information in the local feature library, thereby identifying the model and station number of the target inverter.

[0029] S120. Does the response frame returned by the target inverter match the protocol information of the inverter model currently being attempted? For example, if the data acquisition device can successfully receive the response frame of the target inverter when trying to use a certain protocol information, and the response frame also conforms to the protocol information, it can determine that the target inverter is compatible with the protocol information, execute S130, complete the inverter identification, and stop traversing; if the response frame cannot be received when using the protocol information or the response frame does not conform to the protocol information, it can continue to traverse the next protocol information for trying and judging, and so on, until it determines that the protocol information that the target inverter is compatible with or determines that the target inverter is not compatible with any protocol information in the local feature library.

[0030] S130. Determine the model of the target inverter as the model of the inverter currently being tried and determine the station number of the target inverter, and stop traversing.

[0031] For example, the target inverter adapts to the protocol information currently being attempted, the inverter model of the target inverter is the same as the inverter model currently being attempted, and the station number of the target inverter falls within the range of station numbers currently being attempted. It can be understood that the request frame is sent based on a station number within the range of station numbers. If a response frame from the target inverter is successfully received, and the response frame also conforms to the protocol information, then the station number of the target inverter is the station number that sent the request frame.

[0032] S140. Is the inverter model currently being tried the last inverter model? If yes, proceed to S150; otherwise, return to continue with S110.

[0033] S150, Traversal ends. The response frame returned by the target inverter does not match the protocol information of each inverter model in the local feature library. The response frame is reported to the server to request the server to match the protocol information of the response frame in the cloud feature library.

[0034] In this embodiment, if the response frame returned by the target inverter does not match the protocol information for each inverter model in the local feature library, the response frame is reported to the server to request the server to match the protocol information of the response frame in the cloud feature library. The cloud feature library contains protocol information for a second number of known inverter models, which is greater than the first number. In other words, the cloud feature library stores more comprehensive and abundant protocol information for known inverter models. If the target inverter can be matched to a protocol through local traversal, the inverter identification process ends without server intervention. However, if the target inverter cannot be matched to a protocol through local traversal, the target inverter model is determined to be an unknown model not included in the local library, and then the cloud server performs the matching, achieving cloud-based collaborative identification.

[0035] In one example, the data acquisition device can report data (such as the original message of the response frame) or a specific identification request from an unknown response frame returned by the inverter to the server via a communication module. The server searches a larger feature library for protocol information that matches the structure of the response frame. If a match is found, the server sends the corresponding complete protocol information (including model and station number, etc.) to the data acquisition device. Optionally, the protocol information sent by the server can also include metadata such as data format, data length, and byte order to achieve accurate adaptation to different manufacturers' proprietary protocols.

[0036] In one example, during the cloud-based matching process, the server can record information about the unknown target inverter to update and expand the cloud-based feature library.

[0037] The following is an example of a target inverter identification process: The local feature library stores protocol information for N (N being the first quantity, a positive integer) inverter models, which are: Protocol information 1 includes model 1, manufacturer 1, station number range 1 (e.g., 1-255), and structural characteristics of the data frame 1; Protocol information 2, including model 2, manufacturer 2, station number range 2 such as 1-255, and structural characteristics of data frames 2; ... Protocol information N includes model N, manufacturer N, station number range N (e.g., 1-255), and structural characteristics N of the data frame.

[0038] During the traversal process, the data acquisition device can first attempt to send a request frame to the target inverter using protocol information 1. If a response frame from the target inverter is successfully received for a certain station number x within the station number range, and the response frame also conforms to protocol information 1, then it can be determined that the target inverter is compatible with protocol information 1, the target inverter model is model 1, the station number is x, and the traversal stops. If a response frame cannot be received using protocol information 1 or the response frame does not conform to protocol information 1, then the next protocol information (protocol information 2) can be traversed. Protocol information 2 is used to attempt to send a request frame to the target inverter and make a judgment, and so on, until the protocol information compatible with the target inverter is determined, or it is determined that the target inverter is not compatible with any protocol information in the local feature library. In this case, the server can be requested to perform protocol adaptation in the cloud feature library. The protocol adaptation process of the server in the cloud feature library can refer to the traversal process of the data acquisition device in the local feature library described above.

[0039] This application provides an inverter identification method that can solve the technical problems in the prior art, such as the need to know the device model in advance for inverter data acquisition, the inability to adapt to unknown devices, and the reliance on on-site manual trial and error and program modification. This method combines local active traversal with cloud collaborative query. It first attempts to identify the target inverter by traversing the local feature library. If the identification fails, it can be reported to the server so that the server can match the corresponding protocol information in a more comprehensive cloud feature library. This achieves automatic identification and protocol adaptation of the target inverter even when the inverter model and station number are unknown or even when there is no matching information in the local database.

[0040] In one embodiment, the data acquisition device can dynamically update its local feature library, i.e., communication configuration, based on the inverter model and complete protocol information obtained through local traversal or from the server. Then, it can send a data acquisition request to the target inverter according to the protocol information, receive and parse the inverter data returned by the target inverter, and complete the data acquisition of the target inverter.

[0041] In one embodiment, the local active traversal process of the data acquisition device can be executed by a separate, lower-priority task in the real-time operating system to avoid affecting the real-time performance of other core functions of the data acquisition device (such as environmental sensor data acquisition). This task can be activated when it is determined that the target inverter needs to be identified (e.g., when communication with the target inverter cannot be established).

[0042] In one embodiment, attempting to send a request frame to the target inverter according to the protocol information corresponding to the inverter model includes: according to the station number range corresponding to the inverter model, attempting to send a request frame to the target inverter one by one for each station number in the station number range.

[0043] For each model in the feature library, request frames to read key parameters (such as device ID, model, or standard data point) are sent one by one according to the preset station number range (e.g., 1-255). If a response frame from the target inverter is successfully received and the response frame also conforms to the protocol information, then the station number of the target inverter is the station number currently being tried.

[0044] In one embodiment, the method further includes, before traversing the local feature library: S10. Attempt to send a data acquisition request to the target inverter according to the currently configured protocol information; S20. If the inverter data returned by the target inverter is successfully received, the inverter data is reported to the server. S30. Otherwise, determine that the currently configured protocol information is invalid and start the inverter identification task.

[0045] In this embodiment, before initiating the inverter identification task (in active traversal mode), a data acquisition request can be attempted to be sent according to the currently configured protocol information. This currently configured protocol information can be the default, specified, or most recently used protocol information. If inverter data is successfully received from the target inverter, it indicates that the target inverter is compatible with the currently configured protocol information. In this case, the model and station number of the target inverter can be directly determined to match the current configuration, and there is no need to initiate the inverter identification task. If inverter data is not received from the target inverter, it indicates that the currently configured protocol information is invalid for the target inverter. In this case, the inverter identification task is initiated. Based on this, unnecessary traversal can be avoided, improving inverter identification efficiency.

[0046] Figure 2 This is a schematic diagram illustrating the process of a data acquisition device actively traversing a local feature database, as provided in an embodiment of this application. Figure 2 As shown, the local active traversal process includes: Determine whether the inverter identification task needs to be started. For example, try to send a data acquisition request to the target inverter according to the currently configured protocol information. If the inverter data returned by the target inverter cannot be received, it means that the currently configured protocol information is invalid for the target inverter. In this case, start the inverter identification task. It iterates through each model and station number in the local feature library. First, it attempts to send a request frame with model 0 and station number 0. It determines whether the inverter data frame has been sent based on the data frame sending status flag (ModbusSndMark). If so, it reads the received data frame (i.e., the response frame); otherwise, it re-executes the inverter identification process after a certain delay (e.g., 10ms). If the received data frame is consistent with the protocol information being attempted and matches the data structure of the returned frame in the protocol information being attempted, then the model of the target inverter is determined to be the model of the inverter being attempted, and the station number of the target inverter is determined to be the station number being attempted. If the received data frame is inconsistent with the protocol information currently being tried, or does not match the data structure of the return frame in the protocol information currently being tried, then the station number is incremented by 1, that is, the next station number of the current model is traversed; if all station numbers of the current model (such as 1-255) have been tried and the target inverter has still not been successfully identified, then the inverter model is incremented by 1, that is, the station numbers of the next model are traversed. If all inverter models and station numbers have been tried but the target inverter is still not successfully identified, the flag requiring cloud support will be set to 1, requiring the cloud server to participate in inverter identification. This means that the target inverter will be automatically identified and its protocol adapted by traversing the inverter models and station numbers in the cloud feature library.

[0047] Figure 3This is a schematic diagram of a data acquisition architecture provided in one embodiment. For example... Figure 3 As shown, the data acquisition device executes host Modbus tasks and works collaboratively through multiple tasks within the μCOS-II real-time operating system environment. Among them, the inverter identification process mainly involves the inverter reading task (local active traversal), the mobile data terminal data receiving task (receiving cloud responses), and the cloud-assisted inverter reading task (processing protocols sent from the cloud).

[0048] Building upon the above embodiments, the core of the method in this application lies in "active identification." When the inverter model is unknown, the device actively detects and determines the model and protocol through a combination of device self-detection and cloud-based assistance. This achieves a leap from "passive configuration" to "active adaptation," enabling adaptive data acquisition even when the inverter model is completely unknown. It solves the problem of existing technologies relying on manual model confirmation and on-site programming. In this method, the inverter model does not need to be known in advance. The data acquisition device can automatically identify and complete protocol adaptation through both local traversal and cloud collaboration, solving a major pain point in on-site operation and maintenance, and significantly improving work efficiency and safety. The cloud collaboration mechanism enables the data acquisition device to "learn," allowing it to handle new inverters not included in the local database, greatly enhancing the system's universality and future scalability. The core of the method in this application lies in "active identification." When the model is unknown, the device actively detects and determines the model and protocol through a combination of device self-detection and cloud-based assistance, achieving a leap from "passive configuration" to "active adaptation." Furthermore, this method separates the protocol identification logic from the regular data acquisition logic and uses task scheduling management to make the system software structure clear, which facilitates subsequent maintenance and upgrades.

[0049] Figure 4 A flowchart illustrating another inverter identification method provided in this application embodiment, which can be applied to a server, such as... Figure 4 As shown, the method specifically includes the following steps: S210. Receive a response frame reported by the data acquisition device. The response frame is reported by the data acquisition device when the response frame does not match the protocol information of each inverter model in the local feature library. The local feature library contains protocol information corresponding to a first number of known inverter models. S220. Match the protocol information of the response frame in the cloud feature library according to the response frame. The cloud feature library contains a second number of known inverter models corresponding to protocol information. The second number is greater than the first number. The protocol information includes model identifier and station number range. S230. Send the protocol information matching the response frame to the data acquisition device.

[0050] In this embodiment, the data acquisition device first attempts to identify the target inverter by traversing the local feature library. If identification fails, it can report the issue to the server. Upon receiving the response frame reported by the data acquisition device, the server can initiate a cloud-based traversal mode, traversing a more comprehensive cloud-based feature library. It sequentially attempts to send request frames to the target inverter using various protocol information stored in the cloud-based feature library. Based on the response frame returned by the target inverter (including parameters related to the protocol information), it can determine whether the target inverter matches the protocol information in the cloud-based feature library, thereby identifying the model and station number of the target inverter and sending the corresponding protocol information to the data acquisition device. Based on this, collaborative automatic identification and protocol adaptation of the inverter are achieved.

[0051] Figure 5 This application provides a flowchart illustrating an inverter identification process, as shown in the embodiment. Figure 5 As shown, the inverter identification process includes: Step S101: System initialization.

[0052] After system startup, interrupts are first disabled, and the system clock, μCOS-II real-time operating system timer interrupts, and serial port communication parameters are configured. Operating system tasks are then created. Once task creation is complete, task control is handed over to the μCOS-II real-time operating system's task scheduler, and system interrupts are enabled.

[0053] Step S102: Attempt to read inverter data according to the existing configuration.

[0054] The system first attempts to send a data read request to the inverter via a Modbus task on the host computer, based on the locally saved inverter model and station number configuration. The purpose of this step is to determine if the current configuration is valid and if normal communication with the inverter is possible.

[0055] Step S103: Determine whether the reading was successful.

[0056] The judgment is made based on the communication result of step S102. If a valid data frame (i.e., inverter data) is successfully received from the inverter, the process jumps to step S108 and data reporting is performed directly; if communication fails (e.g., no response after timeout, incorrect data frame format, etc.), the current configuration is determined to be invalid, and the adaptive identification process needs to be started, proceeding to step S104.

[0057] Step S104: Local active traversal mode.

[0058] This mode involves the inverter reading and executing specific tasks; its detailed process can be found in [reference needed]. Figure 2 .

[0059] In local active traversal mode, the inverter protocol feature library stored locally is read sequentially. This feature library contains protocol information corresponding to multiple known inverter models. Each piece of protocol information may include: model identifier, station number range, key data frame structure features, verification method, etc.

[0060] For each model in the feature library, the system attempts to send request frames to read key parameters (such as device ID, device model, or standard data point) one by one according to a preset station number range (usually 1 to 255). After each transmission, the system waits for and parses the response frame returned from the inverter.

[0061] Step S105: Determine whether the local traversal is successful.

[0062] If the structure, length, function code, check value, and other characteristics of the response frame match the protocol characteristics of the currently attempted model, then the inverter model and station number are successfully identified, and the process jumps to step S107 to record the model and the corresponding valid station number.

[0063] If no match is found after iterating through all station numbers for a certain model, switch to the next model in the feature library and repeat the above detection process.

[0064] Step S106: Cloud-based collaborative identification mode.

[0065] If steps S104 and S105 fail to match the target inverter model after traversing the entire local feature library, the system will activate the cloud-based collaborative identification mode.

[0066] This pattern specifically includes the following sub-steps: The data acquisition device reports the unknown response frame data (raw message) or "no response" status information returned by the inverter to the cloud server through a mobile data terminal; After receiving the request, the cloud server will match it in its more comprehensive inverter protocol database to find protocol information that matches the response frame structure. If the match is successful, the cloud server will send the corresponding complete protocol information (including model, address of each data point, data format, data length, byte order, etc.) to the data acquisition device; After the SCI7 interrupt of the data acquisition device receives data from the cloud, it triggers a data receiving task from the mobile data terminal. This task encapsulates the data and triggers a reading task from the cloud auxiliary inverter via email. This task then parses and updates the local protocol configuration.

[0067] Step S107: Update the local protocol configuration.

[0068] Regardless of whether the inverter's protocol information is obtained through local active traversal mode (steps S104-S105) or cloud-based collaborative identification mode (step S106), the data acquisition device dynamically writes the acquired inverter model, station number, and protocol information for each data point into local storage, updating the system communication configuration. Afterward, the host Modbus task can use this protocol information for routine data acquisition.

[0069] Step S108: Collect inverter data and report it.

[0070] According to the finalized protocol configuration, the system sends a regular data acquisition request to the inverter, receives and parses the data returned by the inverter. The acquired inverter data, along with other sensor data (such as solar irradiance, solar radiation intensity, photovoltaic panel temperature, standard photovoltaic panel voltage and current, etc.), is reported to the cloud server via a pass-through task for subsequent photovoltaic capacity analysis and other applications.

[0071] Figure 6 This is a schematic diagram of the structure of an inverter identification device provided in an embodiment of this application. Figure 6 As shown, the inverter identification device provided in this embodiment includes: The traversal module 310 is used to traverse the local feature library to attempt to send a request frame to the target inverter according to the corresponding protocol information for each inverter model in the local feature library. The local feature library contains a first number of known inverter models corresponding to protocol information, and the request frame is used to request to read the parameters related to the protocol information of the target inverter. The identification module 320 is used to determine the model of the target inverter as the currently attempted inverter model and determine the station number of the target inverter if the response frame returned by the target inverter matches the protocol information of the currently attempted inverter model, and then stop traversing. The reporting module 330 is used to report the response frame to the server if the response frame returned by the target inverter does not match the protocol information of each inverter model in the local feature library, so as to request the server to match the protocol information of the response frame in the cloud feature library. The cloud feature library contains a second number of known inverter models corresponding to protocol information, the second number being greater than the first number. The protocol information includes model identifier and station number range.

[0072] The device first attempts to identify the target inverter by traversing the local feature library. If the identification fails, it can report to the server so that the server can match the corresponding protocol information in a more comprehensive cloud feature library, thus realizing automatic identification and protocol adaptation of the inverter.

[0073] Based on any of the above embodiments, the step of attempting to send a request frame to the target inverter according to the protocol information corresponding to the inverter model includes: according to the station number range corresponding to the inverter model, attempting to send a request frame to the target inverter one by one for each station number in the station number range.

[0074] Based on any of the above embodiments, the device further includes: The attempt module is used to attempt to send a data acquisition request to the target inverter according to the currently configured protocol information before traversing the local feature library; The acquisition module is used to report the inverter data to the server if it successfully receives the inverter data returned by the target inverter. The startup module is used to determine that the currently configured protocol information is invalid and start the inverter identification task if the inverter data returned by the target inverter is not successfully received.

[0075] Figure 7 This is a schematic diagram of the structure of an inverter identification device provided in an embodiment of this application. Figure 7 As shown, the inverter identification device provided in this embodiment includes: The receiving module 410 is used to receive a response frame reported by the data acquisition device. The response frame is reported by the data acquisition device when the response frame does not match the protocol information of each inverter model in the local feature library. The local feature library contains protocol information corresponding to a first number of known inverter models. The matching module 420 is used to match the protocol information of the response frame in a cloud feature library according to the response frame. The cloud feature library contains a second number of known inverter models corresponding to protocol information, the second number being greater than the first number. The protocol information includes model identifier and station number range. The sending module 430 is used to send protocol information matching the response frame to the data acquisition device.

[0076] The inverter identification device provided in this application embodiment can be used to execute the inverter identification method provided in any of the above embodiments, and has corresponding functions and beneficial effects.

[0077] Figure 8A schematic diagram of a data acquisition device 10, which can be used to implement embodiments of this application, is shown. The data acquisition device 10 is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The data acquisition device 10 can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, user equipment, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the application described and / or claimed herein.

[0078] like Figure 8 As shown, the data acquisition device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 can also store various programs and data required for the operation of the data acquisition device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0079] Multiple components in the data acquisition device 10 are connected to the I / O interface 15, including: an input unit 16, such as a keyboard, mouse, etc.; an output unit 17, such as various types of displays, speakers, etc.; a storage unit 18, such as a disk, optical disk, etc.; and a communication unit 19, such as a network card, modem, wireless transceiver, etc. The communication unit 19 allows the data acquisition device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks and wireless networks.

[0080] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above.

[0081] In some embodiments, the methods described above can be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program can be loaded and / or installed on the data acquisition device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the methods described above can be performed. Alternatively, in other embodiments, processor 11 can be configured to perform the methods of any of the embodiments described above by any other suitable means (e.g., by means of firmware).

[0082] Figure 9 A schematic diagram of a server 20 that can be used to implement embodiments of this application is shown. Server 20 is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. Server 20 can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, user equipment, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the application described and / or claimed herein.

[0083] like Figure 9 As shown, server 20 includes at least one processor 21 and memory, such as read-only memory (ROM) 12 and random access memory (RAM) 13, communicatively connected to at least one processor 21. The memory stores computer programs executable by at least one processor. Processor 21 can perform various appropriate actions and processes based on the computer program stored in ROM 12 or loaded from storage unit 28 into RAM 13. RAM 23 can also store various programs and data required for the operation of server 20. Processor 21, ROM 22, and RAM 23 are interconnected via bus 24. Input / output (I / O) interface 25 is also connected to bus 24.

[0084] Multiple components in server 20 are connected to I / O interface 25, including: input unit 26, such as keyboard, mouse, etc.; output unit 27, such as various types of monitors, speakers, etc.; storage unit 28, such as disk, optical disk, etc.; and communication unit 29, such as network card, modem, wireless transceiver, etc. Communication unit 29 allows server 20 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks and wireless networks.

[0085] Processor 21 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 21 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 21 performs the various methods and processes described above.

[0086] In some embodiments, the methods described above can be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 28. In some embodiments, part or all of the computer program can be loaded and / or installed on server 20 via ROM 22 and / or communication unit 29. When the computer program is loaded into RAM 23 and executed by processor 21, one or more steps of the methods described above can be performed. Alternatively, in other embodiments, processor 21 can be configured to perform the methods of any of the embodiments described above by any other suitable means (e.g., by means of firmware).

[0087] This application also provides an inverter identification system, such as... Figure 10 As shown, the system includes: a data acquisition device 10 and a server 20 as described in any of the above embodiments.

[0088] Data acquisition device 10 mainly executes the local active traversal process (inverter read task). For details, please refer to [link / reference]. Figure 2 Its core logic is as follows: Task activation conditions: This task is activated when the inverter data acquisition fails or when the user triggers the "Device Identification" command by pressing a button or other means. Traversing the local library: The task first reads the locally stored inverter protocol feature library. In the local feature library, each inverter model corresponds to a feature template, including the expected device model string, the frame header / tail features of the data frame, and / or the checksum method, etc.

[0089] Blindly transmit probe frames: For the selected model, the task starts from station number 1, constructs a standard Modbus request frame for "read device model" or "read device ID", and sends it out through the host Modbus task.

[0090] Result matching: The task waits for and analyzes the received response frames. If the format of the response frame (such as length, function code, and data content) matches the characteristics of the current model template, the identification is considered successful, and the model and station number are recorded.

[0091] Iteration and Termination: If no match is found, increment the station number and repeatedly send probe frames until station number 255 is reached. If all station numbers do not match, switch to the next model template and repeat the above process. If it still fails after traversing all local models, set the "Cloud support required" flag and exit the task.

[0092] Server 20 primarily executes the cloud-based collaborative recognition process (data reception and cloud-based auxiliary tasks), and its core logic is as follows: Triggering Reporting: When the "Requires Cloud Support" flag is set, the pass-through task will package the "Unknown Device Identification Request" and the collected raw response frame data (or "No Response" status information) and upload them to the cloud server.

[0093] Cloud Processing and Distribution: After receiving the request, the cloud server performs a match in its more comprehensive inverter protocol database. Upon successful matching, a configuration package containing complete protocol information (model, addresses of each data point, data type, etc.) is distributed to the data acquisition device.

[0094] Local update: After the SCI7 interrupt of the data acquisition device receives data from the cloud, it triggers the "4G mobile data terminal data receiving task". This task encapsulates the data and triggers the "cloud auxiliary inverter reading task" via email.

[0095] Dynamic loading protocol: The "Cloud-assisted Inverter Reading Task" parses the configuration package sent from the cloud, dynamically writes the obtained inverter model, station number, and protocol information for each data point into local storage, and updates the system configuration. Afterward, the host Modbus task can use this protocol information to complete routine inverter data acquisition.

[0096] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0097] Computer programs used to implement the methods of this application may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0098] In the context of this application, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium can be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0099] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0100] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0101] This application also provides a computer program product, including a computer program and / or instructions, which, when executed by a processor, implement the inverter identification method as described in any of the above embodiments.

[0102] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this application can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this application can be achieved, and this is not limited herein.

[0103] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. An inverter identification method, applied to data acquisition equipment, characterized in that, include: Traverse the local feature library to attempt to send a request frame to the target inverter for each inverter model in the local feature library according to the corresponding protocol information of the inverter model. The local feature library contains a first number of known inverter models corresponding to protocol information. The request frame is used to request to read the parameters of the target inverter related to the protocol information. If the response frame returned by the target inverter matches the protocol information of the currently attempted inverter model, then the model of the target inverter is determined to be the currently attempted inverter model, the station number of the target inverter is determined, and the traversal stops. If the response frame returned by the target inverter does not match the protocol information of each inverter model in the local feature library, the response frame is reported to the server to request the server to match the protocol information of the response frame in the cloud feature library. The cloud feature library contains a second number of known inverter models corresponding to protocol information, the second number being greater than the first number. The protocol information includes model identifier and station number range.

2. The method according to claim 1, characterized in that, The step of attempting to send a request frame to the target inverter according to the protocol information corresponding to the inverter model includes: According to the corresponding station number range of the inverter model, for each station number in the range, a request frame is sent to the target inverter one by one.

3. The method according to claim 1, characterized in that, Before traversing the local feature library, the following is also included: Attempt to send a data acquisition request to the target inverter according to the currently configured protocol information; If inverter data is successfully received from the target inverter, the inverter data is reported to the server. Otherwise, if the currently configured protocol information is determined to be invalid, the inverter identification task will be initiated.

4. An inverter identification method, applied to a server, characterized in that, include: The system receives a response frame reported by a data acquisition device. The response frame is reported by the data acquisition device when the response frame does not match the protocol information of each inverter model in the local feature library. The local feature library contains protocol information corresponding to a first number of known inverter models. According to the response frame, the protocol information of the response frame is matched in the cloud feature library. The cloud feature library contains a second number of known inverter models corresponding to protocol information, the second number being greater than the first number. The protocol information includes model identifier and station number range. The protocol information matching the response frame is sent to the data acquisition device.

5. An inverter identification device, characterized in that, include: The traversal module is used to traverse the local feature library to attempt to send a request frame to the target inverter for each inverter model in the local feature library according to the corresponding protocol information of the inverter model. The local feature library contains a first number of known inverter models corresponding to protocol information. The request frame is used to request to read the parameters of the target inverter related to the protocol information. The identification module is used to determine the model of the target inverter as the currently attempted inverter model and determine the station number of the target inverter if the response frame returned by the target inverter matches the protocol information of the currently attempted inverter model, and then stop traversing. The reporting module is used to report the response frame to the server if the response frame returned by the target inverter does not match the protocol information of each inverter model in the local feature library, so as to request the server to match the protocol information of the response frame in the cloud feature library. The cloud feature library contains a second number of known inverter models corresponding to protocol information, the second number being greater than the first number. The protocol information includes model identifier and station number range.

6. An inverter identification device, characterized in that, include: The receiving module is used to receive response frames reported by the data acquisition device. The response frames are reported by the data acquisition device when the response frames do not match the protocol information of each inverter model in the local feature library. The local feature library contains protocol information corresponding to a first number of known inverter models. The matching module is used to match the protocol information of the response frame in a cloud feature library based on the response frame. The cloud feature library contains a second number of known inverter models corresponding to protocol information, the second number being greater than the first number. The protocol information includes model identifiers and station number ranges. The sending module is used to send protocol information matching the response frame to the data acquisition device.

7. A data acquisition device, characterized in that, include: At least one processor; A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the inverter identification method as described in any one of claims 1-3.

8. A server, characterized in that, include: At least one processor; A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the inverter identification method as described in claim 4.

9. An inverter identification system, characterized in that, include: The data acquisition device as described in claim 7, and the server as described in claim 8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the inverter identification method as described in any one of claims 1-4.

Images