An address management method, system, and computer storage medium based on the Modbus protocol.

Abstract

This invention relates to the field of photovoltaic power plant monitoring and communication technology, and in particular to an address management method, system, and computer storage medium based on the Modbus protocol. The method is applied to a back-end management system, which is communicatively connected to mobile terminals and photovoltaic equipment. This application utilizes the back-end management system to intelligently verify the mapping relationship based on preset logical address planning information, automatically detecting and assisting in correcting potential conflicts to ensure that address allocation is consistent with design drawings. After successful verification, remote batch address modification operations are performed based on the extended Modbus protocol (such as IC function codes), achieving efficient and accurate deployment of logical addresses for photovoltaic equipment. This solves the problems of address duplication, misalignment, and unclear recording in traditional manual configuration methods, improving the automation level and reliability of address management in photovoltaic tracking systems.

Description

Technical Field

[0001] This invention relates to the field of photovoltaic power plant monitoring and communication technology, and in particular to an address management method, system and computer storage medium based on the Modbus protocol. Background Technology

[0002] In photovoltaic (PV) tracking systems, a large number of distributed control devices are typically deployed. These devices communicate with the backend monitoring system via a RS-485 bus network based on the Modbus protocol. In the Modbus protocol, each slave device needs to be assigned a unique address (ID) for the backend system to poll and exchange data. However, in large-scale PV power plants, the number of tracking devices in a single area can reach hundreds, making the proper allocation and management of device addresses crucial for the reliable operation of the system.

[0003] Currently, the industry commonly uses pre-set addresses at the equipment factory or relies on installation personnel to manually configure addresses on-site. This manual approach makes it difficult to ensure that equipment is arranged strictly according to the construction drawings during actual installation, easily leading to problems such as duplicate addresses, misconfigurations, or unclear records. Once address configurations become disordered, the backend system will be unable to accurately identify each device, resulting in abnormal monitoring data and incorrect control commands, subsequently triggering extensive troubleshooting and maintenance work, severely impacting system stability and operational efficiency.

[0004] Therefore, it is necessary to extend the existing Modbus protocol and propose a technical solution that enables automated collection, centralized planning, and remote batch deployment of device addresses to solve the address management problems caused by manual configuration and improve the intelligence level and engineering implementation efficiency of photovoltaic tracking systems. Summary of the Invention

[0005] In view of this, the purpose of the present invention is to provide an address management method, system and computer storage medium based on the Modbus protocol.

[0006] In a first aspect, embodiments of the present invention provide an address management method based on the Modbus protocol, applied to a backend management system, wherein the backend management system is communicatively connected to a mobile terminal and a photovoltaic device, respectively; the method includes: The mapping relationship between the physical information of the device and its installation location sent by the mobile terminal is received. The mapping relationship is verified based on the preset logical address planning information; If the verification passes, a remote batch address modification operation is performed based on the extended Modbus protocol to obtain photovoltaic devices with the target logical addresses.

[0007] In conjunction with the first aspect, the steps for performing remote batch address modification operations based on the extended Modbus protocol to obtain photovoltaic devices with target logical addresses include: The current address and target logical address of each photovoltaic device are determined according to the mapping relationship; Send a custom function code message based on Modbus protocol extension to the photovoltaic device. The custom function code message includes at least a modify address message, which is used to modify the current address of the photovoltaic device to the target logical address. The custom function code is an IC function code, and the modified address message includes a preamble, old address, new address, and verification information.

[0008] In conjunction with the first aspect, before the step of verifying the mapping relationship based on preset logical address planning information, the method further includes: Send a test communication message to the photovoltaic device; wherein the test communication message is based on the IC function code, and its format includes a preamble, old address and verification information, but does not include a new address, and is used to verify the communication status with the photovoltaic device; If the message returned by the photovoltaic device is completely consistent with the content of the test communication message sent, then the verification is confirmed to be successful.

[0009] In conjunction with the first aspect, after the step of verifying the mapping relationship based on preset logical address planning information, the method further includes: The mapping relationship is automatically compared with the target logical location and address allocation rules in the logical address planning information to detect at least one of the following conflicts: multiple devices corresponding to the same logical location, multiple installation locations corresponding to the same physical identity of the device, and the number of devices is inconsistent with the design plan. If a conflict is detected, a prompt message will be output; In response to the user's correction operation, the verification is performed again until a conflict-free mapping relationship between device physical information and logical address is generated, which serves as the basis for performing remote batch address modification operations.

[0010] Secondly, embodiments of this application also provide an address management method based on the Modbus protocol, applied to a mobile terminal, wherein the mobile terminal is communicatively connected to a backend management system and a photovoltaic device, respectively; the method includes: Scan the photovoltaic device to obtain its unique factory identification information. Scan the location markers at the installation site to obtain the physical installation location information of the photovoltaic equipment; Establish a mapping relationship between the factory-unique identification information and the physical installation location information; The mapping relationship is sent to the backend management system, which verifies the mapping relationship based on the preset logical address planning information. After the verification is successful, the system performs a remote batch address modification operation based on the extended Modbus protocol to obtain photovoltaic devices with the target logical address.

[0011] In conjunction with the second aspect, after the step of sending the mapping relationship to the backend management system, the method further includes: Receive the address modification confirmation message returned by the photovoltaic device; The locally maintained device address mapping relationship is updated based on the confirmation message, and the modification status and modification time of each device are recorded.

[0012] Thirdly, this application also provides an address management method based on the Modbus protocol, applied to photovoltaic equipment, wherein the photovoltaic equipment is communicatively connected to a back-end management system and a mobile terminal respectively; the method includes: Receive and respond to the scanning operation of the mobile terminal, and provide the factory-unique identification information stored in the photovoltaic device; Receive custom function code messages based on the extended Modbus protocol sent by the back-end management system; Parse the custom function code message to identify its message type; If the message is identified as a test communication message, and the old address in the test communication message is consistent with its current address, the system will reply with the test communication message as is to confirm that the communication status is good.

[0013] In conjunction with the third aspect, after the step of parsing the custom function code message and identifying its message type, the method further includes: If the message is identified as an address modification message, and the old address in the address modification is consistent with its current address, then the new address in the message is extracted, the communication address is updated to the new address, and an address modification confirmation message is returned to the backend management system.

[0014] Fourthly, this application also provides an address management system based on the Modbus protocol, including: A mobile terminal is used to scan the QR code on the photovoltaic equipment to obtain the factory unique identification information, scan the location mark on the installation location to obtain the physical installation location information, establish a mapping relationship between the factory unique identification information and the physical installation location information, and send the mapping relationship to the background management system. The background management system is communicatively connected to the mobile terminal and multiple photovoltaic devices. It is used to receive the mapping relationship, verify the mapping relationship based on preset logical address planning information, and if the verification is successful, send test communication messages and address modification messages to the photovoltaic devices through IC function codes based on the extended Modbus protocol to modify the device addresses in batches. The photovoltaic equipment has a factory address that is a preset unique number and supports the extended Modbus protocol based on the IC function code. It is used to respond to the scanning operation of the mobile terminal to provide the factory unique identification information, and to receive and respond to the test communication messages and address modification messages sent by the background management system. During test communication, it replies with messages as is, and when the address is modified, it updates its own address and returns confirmation information.

[0015] Fifthly, this application provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the address management method based on the Modbus protocol as described above.

[0016] The embodiments of the present invention bring the following beneficial effects: This application provides an address management method, system, and computer storage medium based on the Modbus protocol. The method is applied to a background management system, which is communicatively connected to a mobile terminal and a photovoltaic device. The method includes: receiving the mapping relationship between the physical information of the device and its installation location sent by the mobile terminal; verifying the mapping relationship based on preset logical address planning information; if the verification passes, performing a remote batch address modification operation based on the extended Modbus protocol to obtain a photovoltaic device with a target logical address.

[0017] This application automatically collects the mapping relationship between the physical identity of the device and its installation location via a mobile terminal, avoiding omissions and errors caused by manual recording. The back-end management system intelligently verifies this mapping relationship based on preset logical address planning information, automatically detects and assists in correcting potential conflicts, ensuring that the address allocation is consistent with the design drawings. After successful verification, remote batch address modification operations are performed based on the extended Modbus protocol (such as IC function codes), achieving efficient and accurate deployment of the logical addresses of photovoltaic devices. In this way, this application can solve the problems of address duplication, confusion, and unclear recording in traditional manual configuration methods, significantly improving the automation level and reliability of photovoltaic tracking system address management, reducing the workload of later operation and maintenance, lowering labor costs and failure risks, and providing strong support for the intelligent operation and maintenance of large-scale photovoltaic power plants.

[0018] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention are realized and obtained in accordance with the structures particularly pointed out in the description, claims and drawings.

[0019] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

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

[0021] Figure 1 This is a flowchart illustrating the address management method based on the Modbus protocol provided in Embodiment 1 of the present invention. Figure 2 This is a schematic diagram of the modified address message structure provided in Embodiment 1 of the present invention; Figure 3 This is a schematic diagram of the test communication message structure provided in Embodiment 1 of the present invention; Figure 4 This is a flowchart illustrating the address management method based on the Modbus protocol provided in Embodiment 2 of the present invention. Figure 5 This is a flowchart illustrating the address management method based on the Modbus protocol provided in Embodiment 3 of the present invention. Detailed Implementation

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

[0023] To facilitate understanding of this embodiment, the technical terms used in this application will be briefly introduced below.

[0024] Photovoltaic tracking system: refers to an automated system that uses a drive mechanism to make photovoltaic modules track the movement of the sun in order to improve power generation efficiency. It usually contains a large number of distributed control devices.

[0025] Modbus protocol: A serial communication protocol widely used in industrial control, which adopts a master-slave architecture, with the background management system acting as the master station to poll each slave device.

[0026] Device Address (ID): In a Modbus network, each slave device needs to be assigned a unique address for master station identification and communication. This application includes the factory-preset original address and the planned target logical address.

[0027] 1C Function Code: This application defines a custom extended function code (hexadecimal 1C) for the Modbus protocol, used to carry two types of instructions: address modification and communication test.

[0028] Preamble: Located in the first byte of the 1C function code message data field, it is used to distinguish different operation types under the same function code. For example, "00" indicates address modification and "01" indicates test communication.

[0029] Test communication message: A 1C function code message containing only a preamble, old address, and checksum information, used to verify the device's online status and address matching status without modifying the address.

[0030] Address Modify Message: A 1C function code message containing a preamble, old address, new address, and checksum information, used to modify the device's current address to the target logical address.

[0031] Logical address planning information: The target logical location and address allocation rules of the equipment generated based on the design drawings, which are used to compare and verify the mapping relationship with the field.

[0032] After introducing the technical terms used in this application, the application scenarios and design concepts of the embodiments of this application will be briefly described below.

[0033] In the process of managing the device addresses of tracking systems in large-scale photovoltaic power plants, which typically contain hundreds of distributed control devices, these devices communicate with the backend via a 485 bus based on the Modbus protocol. Each device needs to be assigned a unique address. Traditionally, this relies on manually recording the factory ID or manually configuring it on-site. However, during construction, it is difficult to install the equipment strictly according to the drawings, often resulting in duplicate, incorrect, or unclear addresses, which in turn leads to errors in backend monitoring and a large amount of subsequent maintenance work.

[0034] Based on this, embodiments of this application provide an address management method, system, and computer storage medium based on the Modbus protocol.

[0035] Example 1 This application provides an address management method based on the Modbus protocol, applied to a back-end management system, which is communicatively connected to a mobile terminal and a photovoltaic device.

[0036] Combination Figure 1 As shown, the method includes: S110 receives the mapping relationship between the physical information of the device and its installation location sent by the mobile terminal.

[0037] S120 verifies the mapping relationship based on preset logical address planning information.

[0038] S130, if the verification passes, perform a remote batch address modification operation based on the extended Modbus protocol to obtain photovoltaic devices with the target logical address.

[0039] This application automatically collects the mapping relationship between the physical identity of the device and its installation location via a mobile terminal, avoiding omissions and errors caused by manual recording. The back-end management system intelligently verifies this mapping relationship based on preset logical address planning information, automatically detects and assists in correcting potential conflicts, ensuring that the address allocation is consistent with the design drawings. After successful verification, remote batch address modification operations are performed based on the extended Modbus protocol (such as IC function codes), achieving efficient and accurate deployment of the logical addresses of photovoltaic devices. In this way, this application can solve the problems of address duplication, confusion, and unclear recording in traditional manual configuration methods, significantly improving the automation level and reliability of photovoltaic tracking system address management, reducing the workload of later operation and maintenance, lowering labor costs and failure risks, and providing strong support for the intelligent operation and maintenance of large-scale photovoltaic power plants.

[0040] Step S110 forms the data acquisition foundation for the address management process. During the on-site construction phase of the photovoltaic power station, equipment installers scan the QR code on the equipment itself using mobile terminals (such as mobile phones, tablets, etc.) to obtain the equipment's unique factory identification information (i.e., physical identity). Simultaneously, the mobile terminal scans the location identification QR code installed on the bracket or array to automatically obtain the physical installation location information of the equipment, such as array number, row number, column number, or bracket number. In this way, the system automatically establishes the original correspondence between the physical identity of each piece of equipment and its actual installation location during on-site construction, and temporarily stores this mapping relationship in the mobile terminal or on-site gateway. Subsequently, the mobile terminal uploads this mapping relationship to the back-end management system via a wireless network. Step S110 transforms the traditional method of relying on manual recording into automated data collection, eliminating omissions, errors, or confusions that may result from manual recording at the source, thus providing an accurate and reliable data source for subsequent logical address planning.

[0041] Step S120 is a key quality control step in the entire address management process. After receiving the "physical identity - installation location" mapping relationship collected on-site, the back-end management system will automatically compare it with the pre-imported system design drawings or logical planning information.

[0042] Understandably, the design drawings include the intended logical locations of the equipment and the preset logical address allocation rules. The backend management system uses intelligent algorithms to cross-validate the two sets of data, focusing on detecting the following potential conflicts: whether the same logical location corresponds to multiple physical devices, whether the same physical device is recorded in multiple installation locations, and whether the number of devices actually installed on-site matches the number planned in the design drawings. Once any of the above conflicts or inconsistencies are detected, the system will assist maintenance personnel in manual review and correction through prompts, marking, or recommended correction schemes. Only when all data passes verification and ensures that the actual on-site installation is completely consistent with the design plan will the backend management system generate a conflict-free "physical identity - logical address" mapping relationship as the basis for subsequent remote address deployment. This step ensures that the logical address of each device accurately corresponds to its physical location and design intent.

[0043] In conjunction with the first aspect, step S130 includes: S131, determine the current address and target logical address of each photovoltaic device according to the mapping relationship.

[0044] S132, send a custom function code message based on Modbus protocol extension to the photovoltaic device. The custom function code message includes at least a modify address message, which is used to modify the current address of the photovoltaic device to the target logical address.

[0045] The custom function code is the 1C function code, and the address modification message includes a preamble, old address, new address, and verification information.

[0046] In the preceding steps, the backend management system has generated an accurate "physical identity - logical address" mapping relationship through on-site data collection and intelligent verification. Based on this, step S130 is further subdivided into two sub-steps, S131 and S132, which use the extended Modbus protocol to achieve remote batch reconfiguration of photovoltaic device addresses.

[0047] Specifically, step S131 is the data preparation stage for address modification. The backend management system extracts the current address (i.e., the original ID preset at the factory or the old address left on-site) and the planned target logical address for each photovoltaic device from the verified mapping relationship. By establishing this correspondence, the system clarifies the modification operations that need to be performed on each device, ensuring the relevance and accuracy of subsequent instructions and avoiding misoperations caused by ambiguity in the address correspondence.

[0048] Step S132 describes the specific execution process of address modification. The background management system, based on the extended Modbus protocol, uses a custom IC function code to construct address modification messages and sends them in batches to field devices via the 485 bus network.

[0049] like Figure 2 As shown, the address modification message includes a preamble (to identify the message as an extended instruction), the old address (used to match the target device), the new address (i.e., the target logical address), and verification information (to ensure the integrity of data transmission). When the photovoltaic device receives this message, it first compares the old address in the message with its own current address. If they match, it performs an address modification operation, updating its own address to the new address, thereby achieving remote reconstruction of the logical address. By sending such messages in batches, the system can efficiently and accurately complete the unified address deployment of hundreds of devices throughout the power station, completely solving the problems of low efficiency and error-proneness of traditional manual modification methods.

[0050] Specific combination Figure 2 The Modbus protocol custom function code extended in this application is 1C. Its address modification message structure explicitly includes a preamble field, identified by "00". The purpose of the preamble is to extend the semantics of the function code within the standard Modbus protocol framework by adding a custom identifier, enabling the device to accurately identify the specific operation type of the current message while avoiding conflicts with standard Modbus function codes.

[0051] In an address modification message, the preamble "00" indicates to the receiving device that this message is an address modification instruction, not another type of extended instruction. Upon receiving the 1C function code message, the device first parses the preamble field: if the preamble is detected as "00", it determines that the message is an address modification operation, and then continues to parse the old address, new address, and checksum information in the message, and executes the address modification process. If the preamble is another value (e.g., ...), the device will not modify the address modification process. Figure 3 If the test communication message uses different preambles, such as "01" or other preset values, the device will recognize it as a different function (such as testing communication without modifying the address).

[0052] By employing a differentiated design for the preamble, this application achieves the goal of carrying multiple different operations under the same function code (IC), thus expanding the functionality of the Modbus protocol while maintaining the simplicity and scalability of the message structure. This allows the backend management system to flexibly send different types of instructions to the device, while the device can quickly distinguish and accurately respond based on the preamble, thereby providing reliable protocol support for remote batch address management.

[0053] Combination Figure 2 The Modify Address message is an extension based on the standard Modbus protocol framework. Its message structure includes the following fields: slave address, function code, data field (preamble, old address, new address), and checksum. Figure 2The focus is on showcasing the composition of the data field, while Figure 3 This demonstrates the differences in the data fields of the test communication messages. The following is a detailed explanation of each field: 1. Slave Address Field: This field, located at the very beginning of the message, specifies the target device for this communication. In actual batch address modification scenarios, this field is typically set to a broadcast address (e.g., 0x00) so that all photovoltaic devices on the bus can receive the message. The device then performs a secondary match using the "old address" field in the data field, ensuring that only devices whose current address matches the old address perform the modification operation. The slave address is an inherent field of the standard Modbus protocol and is essential as a fundamental component of the message. Figure 2 It was not marked separately.

[0054] 2. Function Code Field: Following the slave address, the function code is a custom value of 1C (hexadecimal), used to identify that the message belongs to the extended protocol scope of this application. The device identifies that the message needs to be processed according to the extended rules by parsing the function code. Figure 2 and Figure 3 Both are clearly marked with the function code 1C, indicating that the two types of operations, address modification and communication testing, share the same function code, and their specific functions are distinguished by the subsequent preamble.

[0055] 3. The data field is the core content of the extended protocol, such as... Figure 2 As shown, the data field of a modified address message consists of three parts: a preamble, the old address, and the new address. Preamble: occupies 1 byte, and its value is "00" (e.g., ...). Figure 2 As shown), this is used to identify that the operation is an address modification. After receiving the message, the device first parses the preamble. If it is "00", it is determined to be an address modification instruction; if it is any other value (such as...), it is considered a different instruction. Figure 3 If the preamble "FC" is present in the test communication message, it is determined to be another operation (such as a communication test). The design of the preamble enables the multiplexing of multiple operations under the same function code.

[0056] Old Address: This value represents the device's current address (factory ID or legacy address), occupying 2 bytes. It consists of the high byte of the old address (see oldAddress>>8 in the diagram) and the low byte of the old address (see oldAddress&0xFF in the diagram). The device compares this field with its current address, and only performs subsequent modifications if they match, ensuring that instructions are accurately delivered to the target device.

[0057] New Address: This value represents the planned target logical address, occupying 2 bytes. The bytes are the high byte (see `newAddress>>8` in the diagram) and the low byte (see `newAddress&0xFF` in the diagram). After confirming a match with the old address, the device updates its own address to this field, completing the address modification.

[0058] 4. Check field, located at the end of the message, is the standard Modbus protocol CRC check (cyclic redundancy check), used to verify whether an error occurred during message transmission. Figure 2 The "verification" field marked in the text refers to this field, which ensures the accuracy and reliability of address modification commands.

[0059] The data field of the test communication message only contains the preamble (with a preset value different from that of the address modification message, such as "FC") and the old address, but not the new address. After the device parses the preamble as "FC", it determines that this command is a communication test, only verifies the old address match and replies with the message as is, without performing any address modification operation. Through the differentiated design of the preamble, this extended protocol, while maintaining a simple message structure, achieves flexible switching between the two major functions of address modification and communication testing, providing reliable protocol support for remote batch address management.

[0060] In conjunction with the first aspect, prior to step S120, the following also includes: S111, send a test communication message to the photovoltaic equipment; the test communication message is based on the 1C function code, and its format includes a preamble, old address and verification information, but does not include a new address, and is used to verify the communication status with the photovoltaic equipment.

[0061] S112, if the message returned by the photovoltaic device is completely consistent with the content of the test communication message sent, then the verification is confirmed to be successful.

[0062] Step S111 aims to perform a communication pre-verification of the target device using the extended Modbus protocol before address modification, ensuring the reliability of subsequent modification operations. For example... Figure 3 As shown, the test communication message also uses a custom 1C function code, but its message structure differs significantly from the address modification message: the message consists of a preamble, the old address, and checksum information, and does not contain a new address field. The preamble is designed to distinguish different operation types under the same function code, specifically as follows: Figure 2 The preamble of the modified address message is set to "00", while Figure 3 The preamble "FC" in the test communication message shown uses a different value (e.g., it can be set to "01" or other preset values) to identify this command as a communication test. The old address field is used to specify the current address of the device under test, while the verification information ensures the integrity of the message transmission.

[0063] When the photovoltaic device receives the message via the 485 bus, it first parses the preamble field. If the preamble value corresponds to the test communication function (e.g., "01"), the device determines that this instruction is a communication test, not an address modification. Subsequently, the device compares the old address in the message with its own current address: if they match, the device confirms that the message is a test instruction sent to itself; if they do not match, the device ignores the message or returns an exception.

[0064] In step S112, the accuracy of the communication status and address information is determined based on the device's response to the test communication message.

[0065] According to the extended protocol design, when a device determines that the old address in the test communication message matches its own address, it will perform an "as is" response: that is, it will return the received test communication message (including the preamble, old address, and verification information) completely unchanged to the backend management system. This response mechanism has dual verification significance: on the one hand, it proves that the device is online and the communication link is normal; on the other hand, it verifies that the device's current address completely matches the old address in the message, that is, the "current address" recorded by the backend is accurate.

[0066] After sending a test communication message, the backend management system waits for a response from the device. If a response message is received within the specified time and compared byte-by-byte with the previously sent message, confirming that the two messages are completely identical, the verification step is considered successful. This result means that the device is accessible, the address information is correct, and it can correctly parse extended protocol instructions, thus meeting the conditions for subsequent address modification.

[0067] If the backend does not receive a response, or the returned message is inconsistent with the sent message (e.g., verification error, data distortion, etc.), the verification is deemed to have failed. At this point, the system marks the device as abnormal and prompts maintenance personnel to investigate communication failures or address conflicts. This avoids blindly sending modification commands when the status is unclear, effectively preventing the risk of address modification failure due to communication anomalies. Through the pre-verification of S111 and S112, a reliable communication foundation is established for remote batch address modification, significantly improving the overall stability and success rate of the operation.

[0068] In conjunction with the first aspect, after step S120, the following is also included: S140, automatically compare the mapping relationship with the target logical location and address allocation rules in the logical address planning information, and detect whether there is at least one of the following conflicts: multiple devices corresponding to the same logical location, multiple installation locations corresponding to the same physical identity of the device, or the number of devices is inconsistent with the design plan.

[0069] S150: If a conflict is detected, a prompt message will be output.

[0070] S160, in response to the user's correction operation, performs verification again until a conflict-free mapping relationship between device physical information and logical address is generated, which serves as the basis for performing remote batch address modification operations.

[0071] Step S140 involves the backend management system performing a deep verification after receiving the mapping relationship collected from the field. Understandably, the backend management system has pre-imported the photovoltaic power station's design drawings or logical planning information, which includes the target logical location of each device (such as array number, row number, column number, etc.) and preset logical address allocation rules (such as assigning IDs according to location order). The system automatically compares the "physical identity—installation location" mapping relationship collected from the field with this planning information, focusing on detecting three typical conflicts: The first type is multiple devices corresponding to the same logical location. That is, the design drawings specify that a certain location should be installed with one device, but the data collected on site shows that the location is associated with multiple different physical devices. This usually indicates that multiple devices were mistakenly installed in the same location or the location identifier was scanned repeatedly during construction.

[0072] The second type is where the same physical identity of a device corresponds to multiple installation locations. That is, the unique factory identifier of a certain device appears in multiple different installation location records. This usually means that the device has been scanned repeatedly, or the record has not been updated after the device was moved.

[0073] The third category is the discrepancy between the number of devices and the design plan. That is, there is a difference between the total number of devices collected on site and the number of devices planned in the design drawings. There may be some extra devices or some missing devices, reflecting the situation of installation omissions or redundant installations.

[0074] Through the above-mentioned automatic comparison and conflict detection, the system can comprehensively identify the deviations between the on-site installation and the design drawings, providing an accurate basis for subsequent correction.

[0075] Upon discovering the aforementioned conflict, step S150 involves an interactive process of issuing warnings and guidance to maintenance personnel. When the backend management system detects any type of conflict through automatic comparison, it will not directly interrupt the process but will instead output a visual prompt message. The specific content of the prompt message varies depending on the type of conflict: for conflicts where "multiple devices correspond to the same logical location," the backend management system will list the logical location and the physical identities of the multiple associated devices; for conflicts where "the same physical identity corresponds to multiple installation locations," the backend management system will display the physical identity of the device and its multiple location records; for conflicts where "the number of devices is inconsistent with the design plan," the backend management system will calculate the difference between the actual number and the planned number and mark the missing or extra location areas.

[0076] The notification information can be presented as a pop-up window, a highlighted marker, or a conflict list, allowing operations and maintenance personnel to intuitively see the problem through the backend management interface. This clarifies and visualizes complex conflict situations, reducing the difficulty for operations and maintenance personnel in troubleshooting and providing clear guidance for subsequent manual correction.

[0077] Afterwards, maintenance personnel manually intervened and corrected the conflict issues based on the system's output prompts. Correction operations may include: for cases where multiple devices correspond to the same logical location, confirming the correct device installed and deleting redundant records; for cases where the same device has multiple physical locations, verifying the actual installation location of the device and retaining the correct record; and for cases where the number of devices does not match the design plan, supplementing the missing device or removing redundant devices, and updating the on-site data.

[0078] After the correction is completed, the operations and maintenance personnel submit the updated mapping relationship through the backend management system. The system then performs another verification, repeating the conflict detection process in step S140. If conflicts still exist, the system continues to output prompts to guide the operations and maintenance personnel to make further corrections. If the verification passes, all conflicts are resolved, and the system finally generates a conflict-free "physical identity - logical address" mapping relationship.

[0079] This mapping relationship is the final result of accurately matching on-site collected data with design planning information. It clearly records the physical identity, current address (factory ID), and planned target logical address of each photovoltaic device. The backend management system will use this mapping relationship as a basis to execute subsequent remote batch address modification operations (step S130). Through the verification and correction closed loop from S140 to S160, this solution ensures that the logical address of each device strictly corresponds to its physical location and design intent, providing a fundamental guarantee for the accuracy and reliability of address modification.

[0080] Example 2 This application provides an address management method based on the Modbus protocol. Compared to the embodiments described, the difference lies in that the method provided in this embodiment is applied to a mobile terminal. The mobile terminal is communicatively connected to the backend management system and photovoltaic equipment in Embodiment 1, respectively. Figure 4 As shown, the method includes: S210, scan the photovoltaic equipment to obtain the unique factory identification information of the photovoltaic equipment.

[0081] S220 scans the location markers at the installation site to obtain information about the physical installation location of the photovoltaic equipment.

[0082] S230 establishes a mapping relationship between the factory-unique identification information and the physical installation location information.

[0083] S240 sends the mapping relationship to the backend management system, so that the backend management system can verify the mapping relationship based on the preset logical address planning information, and perform remote batch address modification operation based on the extended Modbus protocol after the verification is passed, so as to obtain photovoltaic devices with target logical addresses.

[0084] Step S210, the first data collection operation performed by the mobile terminal during the on-site construction phase of a photovoltaic power station, aims to accurately acquire the physical identity information of each photovoltaic device through automation. When the equipment leaves the factory, the manufacturer assigns a unique identifier (such as a factory ID) to each photovoltaic device and prints it on the device in the form of a QR code. Upon arrival at the site, construction personnel use the built-in scanning function of a mobile terminal (such as a mobile phone or tablet) to scan the QR code on the device. The mobile terminal automatically parses the encoded unique factory identifier information of the device using QR code recognition technology, including but not limited to key data such as the serial number, production batch, and equipment model. This process completely replaces traditional manual recording methods, avoiding omissions, errors, or illegible handwriting caused by handwriting, verbal descriptions, or paper records, ensuring that the physical identity information of each device is accurately and quickly collected and entered into the system.

[0085] Steps S220 and S210 are executed synchronously or sequentially to obtain accurate information about the actual installation location of the equipment, laying the foundation for establishing the correspondence between the equipment and the location in the future.

[0086] Location marker QR codes are pre-installed on the support or array structure of photovoltaic power plants. These QR codes encode detailed physical location information, such as array number, row number, column number, support number, or geographical coordinates. After installation, construction personnel can use a mobile terminal to scan the location marker QR codes near the equipment to automatically obtain its specific physical location information. In this way, the mobile terminal records the equipment's installation location in the form of structured data, avoiding inaccuracies, inconsistencies, or omissions that may occur when manually describing or filling in location information. This provides an accurate location basis for establishing subsequent mapping relationships.

[0087] After the mobile terminal obtains the device's unique factory identifier (via step S210) and the device's physical installation location information (via step S220), it associates and stores these two pieces of data in local memory or temporary storage as key-value pairs or record bars, forming a complete "physical identity - installation location" mapping record. This mapping relationship clearly identifies "which device" is installed at "which specific location." The mobile terminal can support scanning and mapping of multiple devices consecutively. Each time a device is installed, the construction personnel execute operations S210 to S230 once, ultimately creating a complete original mapping dataset on-site that perfectly matches the actual installation. This process rigidly binds the device to its physical location, providing a reliable on-site data foundation for the backend management system to perform logical address planning.

[0088] After completing the on-site scanning and mapping relationship establishment for a region or all devices in step S240, the mobile terminal uploads the stored "physical identity - installation location" mapping dataset to the backend management system via a wireless network (such as 4G / 5G, Wi-Fi, or on-site LAN). The uploaded data format can be a structured text file, JSON data packet, or database record, ensuring that the backend system can accurately parse and read it.

[0089] After receiving this mapping data, the backend management system automatically verifies and detects conflicts according to the preset logical address planning information (such as design drawings, address allocation rules, etc.) (corresponding to S120 and S140 to S160 in the first aspect embodiment). Only when all data passes the verification and a conflict-free "physical identity - logical address" mapping relationship is generated will the backend system perform a remote batch address modification operation based on the extended Modbus protocol (such as IC function code) (corresponding to S130 in the first aspect embodiment), modifying the current address of each photovoltaic device to the target logical address.

[0090] By executing steps S210 to S240, the mobile terminal successfully played the role of a field data collector, converting the physical installation status of the equipment into digital information and transmitting it to the backend, providing an indispensable data source support for the intelligent and automated management of the entire photovoltaic power station's equipment locations.

[0091] In this embodiment, the mobile terminal serves as an on-site construction assistance tool. The mobile terminal has a built-in QR code scanning module and parsing algorithm, enabling it to accurately identify the encoded content in the equipment QR code and location identification QR code. The equipment QR code contains at least a unique factory identifier (such as a factory ID), and the location identification QR code contains at least structured location encoding information (such as "array A-row 05-column 12").

[0092] Meanwhile, the mobile terminal has local data caching capabilities, allowing it to temporarily store established mapping relationship data in areas without network coverage. Once the network is restored, it supports resume downloading or batch uploading, ensuring no data loss or omission. Additionally, the mobile terminal can perform simple integrity checks on the collected data, such as alerting for duplicate scans or missed scans.

[0093] In addition, the mobile terminal provides a visual operation interface that displays the scanning results and mapping relationship establishment status in real time. When scanning anomalies occur (such as damaged QR codes or incorrect formats) or data conflicts occur (such as the same device being scanned repeatedly to different locations), the mobile terminal can issue prompts immediately to guide construction personnel to verify and correct the data on-site, ensuring the accuracy of the data collected on-site.

[0094] In conjunction with the first aspect, after step S240 sends the mapping relationship to the backend management system, the method further includes: S241, Receive the address modification confirmation message returned by the photovoltaic device.

[0095] S242, update the locally maintained device address mapping relationship according to the confirmation message, and record the modification status and modification time of each device.

[0096] After the remote batch address modification operation is executed in the background management system in step S240 (i.e., step S130 in the first aspect), the photovoltaic equipment will return a confirmation response message to the background management system according to the Modbus protocol specification when it successfully modifies its own address. This response message is received and parsed by the background management system, which then encapsulates the modification results (including the device's new address, modification success status, etc.) into a notification message and sends it to the mobile terminal via the wireless network. The mobile terminal receives this notification, thus learning the address modification status of each device. This process achieves closed-loop synchronization between on-site data collection and background modification results, enabling the mobile terminal to monitor device address changes in real time and providing accurate data for subsequent on-site operation and maintenance.

[0097] After receiving the address modification confirmation information forwarded by the backend management system, step S242 updates the locally stored "physical identity - logical address" mapping relationship: updating the device's current address to the modified target logical address, and recording the device's modification status (e.g., "modified" or "modification failed") and the specific modification timestamp. For devices where modification failed, the mobile terminal can generate an error message to remind maintenance personnel to check the cause on-site (e.g., device offline, communication failure, etc.). Through this local data update, the mobile terminal always maintains a mapping relationship that is completely consistent with the actual on-site device address, providing reliable data support for subsequent on-site inspections, fault diagnosis, and equipment replacement, further improving the traceability and maintenance efficiency of photovoltaic power station address management.

[0098] The address modification confirmation message involved in this step is triggered by the address modification message sent by the backend management system. For example... Figure 2 As shown, the preamble in the address modification message is set to "00", indicating that the message is an address modification type under function code 1C. After receiving this message, the photovoltaic device identifies the operation type by parsing the preamble and returns an acknowledgment response upon successful address modification. The acknowledgment information received by the mobile terminal is generated based on this response. Therefore, the design of the preamble indirectly ensures the correct identification and execution of the address modification operation, guaranteeing that the acknowledgment information received by the mobile terminal strictly corresponds to the modification command sent from the backend.

[0099] Example 3 This application provides an address management method based on the Modbus protocol, which differs from embodiments 1 and 2 in that it is applied to photovoltaic equipment. The photovoltaic equipment is communicatively connected to the backend management system provided in embodiment 1 and the mobile terminal provided in embodiment 2, respectively. Figure 5 As shown, the method includes: S310 receives and responds to the scanning operation of the mobile terminal, providing the factory-unique identification information stored in the photovoltaic equipment.

[0100] The S320 receives custom function code messages based on the extended Modbus protocol sent by the backend management system.

[0101] S330 parses custom function code messages and identifies their message type.

[0102] If S340 identifies the message as a test communication message and the old address in the test communication message matches its current address, it replies to the backend management system with the test communication message as is to confirm that the communication status is good.

[0103] Step S310 is a fundamental step in the interaction between the photovoltaic equipment and the mobile terminal during the on-site construction phase, aiming to accurately transmit the equipment's physical identification information to the mobile terminal. When the photovoltaic equipment leaves the factory, the manufacturer assigns each unit a unique factory identification information (such as a factory ID, usually sequentially numbered starting from 300), and prints this information as a QR code on the equipment's nameplate or casing. It can also be stored in a readable storage unit inside the equipment via Near Field Communication (NFC) or Bluetooth. When construction personnel use a mobile terminal to scan on-site, the photovoltaic equipment is scanned and identified by the mobile terminal through its QR code, or responds to the mobile terminal's read request through the NFC module, providing the mobile terminal with the unique factory identification information stored in the photovoltaic equipment (such as the factory ID, equipment model, production batch, etc.). This process achieves automatic and accurate reading of the equipment's physical identification information, providing a reliable data source for subsequently establishing the mapping relationship between the equipment and its installation location, and avoiding errors that may be caused by manual recording.

[0104] Step S320 is the communication stage in the address management process where the photovoltaic device receives remote commands, marking the transition from the field data acquisition stage to the remote configuration stage. After the background management system verifies the field mapping data and generates a conflict-free "physical identity - logical address" mapping relationship, it sends extended Modbus protocol messages to the field photovoltaic device via the 485 bus network. These messages use a custom function code 1C (hexadecimal) to distinguish them from the standard Modbus function code. The photovoltaic device, acting as a slave on the bus, constantly listens to the communication data on the bus. When it detects that the function code field in the message is 1C, it recognizes that the message belongs to the extended protocol provided in this application and receives it for further parsing and processing. This step ensures that the device can accurately capture the remote configuration commands sent by the background system.

[0105] Step S330 is the core step in the photovoltaic equipment's intelligent parsing of the received extended protocol messages, aiming to distinguish different operational intentions based on the message content. After receiving a message with function code 1C, the equipment first extracts the first byte from the message data field—the preamble field, such as... Figure 2 and Figure 3 As shown. The value of the preamble determines the specific type of the message: if the preamble is "00", the device determines that the message is an address modification message; if the preamble is "FC" (or other preset value different from "00"), the device determines that the message is a test communication message. Through this parsing mechanism, the device can distinguish between two different operations under the same function code, avoiding instruction confusion and providing a basis for accurate subsequent responses. Simultaneously, the photovoltaic device will also extract the old address field from the message for later comparison with its current address.

[0106] S340 refers to the specific behavior of photovoltaic equipment in responding to test communication commands. When the photovoltaic equipment identifies the current message as a test communication message by parsing the preamble (e.g., ...), ... Figure 3 As shown, after the preamble is "FC", the old address field in the message will be further extracted and compared with the current address stored in the device (i.e., the current Modbus slave address of the device). If the two match, it indicates that the message is indeed a test command sent to this device; if they do not match, an error message will be returned according to the protocol implementation.

[0107] If the old address matches successfully, the device, according to the extended protocol, performs an "as is" response: it returns the received test communication message (including the preamble "FC", the old address, and verification information) completely unchanged to the backend management system via the RS-485 bus. This response mechanism has dual verification significance: firstly, it proves to the backend that the device is online and the communication link is normal; secondly, it verifies that the device's current address is completely consistent with the old address recorded by the backend, ensuring the accuracy of subsequent address modification operations. Through this step, the backend system can confirm the correctness of the communication status and address information in advance without actually modifying the address, establishing a reliable execution prerequisite for subsequent remote batch address modifications.

[0108] In conjunction with the first aspect, after step S330, the following also includes: If the S350 identifies an address modification message and the old address in the address modification message is consistent with its current address, it extracts the new address from the message, updates its own communication address to the new address, and returns an address modification confirmation message to the backend management system.

[0109] When the device identifies the current message as an address modification message by parsing the preamble (e.g.) Figure 2 As shown, the preamble value is "00". The device further extracts the old address field from the message and compares it with its stored current address (i.e., the device's current Modbus slave address). If they match, it indicates that the modification instruction was indeed sent to this device; if they do not match, the photovoltaic device returns an error message and does not perform any modification operation.

[0110] If the old address matches successfully, the device extracts the new address field from the message data field (e.g., ...). Figure 2 As shown (the new address immediately follows the old address), this value is written to its own communication address register, completing the update from the current address to the target logical address. This operation permanently modifies the device's Modbus slave address to the new address, which the device will then use to communicate with the backend management system.

[0111] After the address modification is successful, the device returns an address modification confirmation message to the backend management system according to the Modbus protocol specification. This confirmation message can be a standard Modbus response frame (e.g., returning the same function code as the modification message, or a data field carrying a successful modification status). Its specific format depends on the protocol implementation, but it should at least contain sufficient information for the backend management system to confirm that the modification operation has been completed. Upon receiving the confirmation message, the backend management system can determine that the device's address modification was successful and update its maintained device address mapping relationships.

[0112] Through step S350, the photovoltaic equipment accurately responds to backend commands to complete address modification without manual on-site intervention, and feeds the results back to the backend, thus forming a complete closed loop for remote batch address deployment. This process completely solves the problems of low efficiency and error-proneness of traditional manual modification methods, providing key technical support for the intelligent operation and maintenance of large-scale photovoltaic power plants.

[0113] Example 4 Secondly, this application provides an address management system based on the Modbus protocol, which includes: a mobile terminal, a background management system, and a photovoltaic device; the mobile terminal is used to execute the method provided in Embodiment 2, the background management system is used to execute the method provided in Embodiment 1, and the photovoltaic device is used to execute the method provided in Embodiment 3.

[0114] The mobile terminal is used to scan the QR code on the photovoltaic equipment to obtain the unique factory identification information, scan the location mark on the installation location to obtain the physical installation location information, establish a mapping relationship between the unique factory identification information and the physical installation location information, and send the mapping relationship to the back-end management system.

[0115] The backend management system communicates with mobile terminals and multiple photovoltaic devices to receive mapping relationships. It verifies the mapping relationships based on preset logical address planning information. If the verification passes, it sends test communication messages and address modification messages to the photovoltaic devices via IC function codes based on the extended Modbus protocol to modify device addresses in batches.

[0116] Photovoltaic equipment has a factory address with a preset unique number and supports the extended Modbus protocol based on the 1C function code. It is used to respond to the scanning operation of the mobile terminal to provide the factory unique identification information, as well as to receive and respond to the test communication messages and address modification messages sent by the background management system. During test communication, it replies to the message as is, and when the address is modified, it updates its own address and returns confirmation information.

[0117] Among them, the mobile terminal, photovoltaic equipment and the electronic equipment used in the back-end management system all include a memory and a processor. The memory is used to store computer programs, and the processor runs the computer programs to enable the electronic equipment to perform the above-mentioned methods.

[0118] Furthermore, it also includes a bus and communication interface, with the processor, communication interface, and memory connected via the bus.

[0119] The memory may include high-speed random access memory (RAM) and may also include non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface (which can be wired or wireless), such as the Internet, wide area network, local area network, metropolitan area network, etc. The bus can be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into address bus, data bus, control bus, etc.

[0120] The processor may be an integrated circuit chip with signal processing capabilities. In implementation, the steps of the above methods can be completed by integrated logic circuits in the processor's hardware or by software instructions. The processor can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this invention. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this invention can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in the memory, and the processor reads the information in the memory and, in conjunction with its hardware, completes the steps of the method described in the foregoing embodiments.

[0121] Thirdly, embodiments of this application provide a readable storage medium storing computer program instructions, which are read and executed by a processor to perform the above-described method.

[0122] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the system and apparatus described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0123] Furthermore, in the description of the embodiments of the present invention, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in the present invention based on the specific circumstances.

[0124] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0125] In the description of this invention, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing the invention and for simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the invention. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0126] Finally, it should be noted that the above embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. An address management method based on the Modbus protocol, characterized in that, The method is applied to a back-end management system, which is communicatively connected to a mobile terminal and photovoltaic equipment, respectively; the method includes: The mapping relationship between the physical information of the device and its installation location sent by the mobile terminal is received. The mapping relationship is verified based on the preset logical address planning information; If the verification passes, a remote batch address modification operation is performed based on the extended Modbus protocol to obtain photovoltaic devices with the target logical addresses.

2. The method according to claim 1, characterized in that, The steps for performing remote batch address modification operations based on the extended Modbus protocol to obtain photovoltaic devices with target logical addresses include: The current address and target logical address of each photovoltaic device are determined according to the mapping relationship; Send a custom function code message based on Modbus protocol extension to the photovoltaic device. The custom function code message includes at least a modify address message, which is used to modify the current address of the photovoltaic device to the target logical address. The custom function code is an IC function code, and the modified address message includes a preamble, old address, new address, and verification information.

3. The method according to claim 1, characterized in that, Before the step of verifying the mapping relationship based on preset logical address planning information, the method further includes: Send a test communication message to the photovoltaic device; wherein the test communication message is based on the IC function code, and its format includes a preamble, old address and verification information, but does not include a new address, and is used to verify the communication status with the photovoltaic device; If the message returned by the photovoltaic device is completely consistent with the content of the test communication message sent, then the verification is confirmed to be successful.

4. The method according to claim 3, characterized in that, After the step of verifying the mapping relationship based on preset logical address planning information, the method further includes: The mapping relationship is automatically compared with the target logical location and address allocation rules in the logical address planning information to detect at least one of the following conflicts: multiple devices corresponding to the same logical location, multiple installation locations corresponding to the same physical identity of the device, and the number of devices is inconsistent with the design plan. If a conflict is detected, a prompt message will be output; In response to the user's correction operation, the verification is performed again until a conflict-free mapping relationship between device physical information and logical address is generated, which serves as the basis for performing remote batch address modification operations.

5. An address management method based on the Modbus protocol, characterized in that, The method is applied to a mobile terminal, which is communicatively connected to a backend management system and photovoltaic equipment, respectively; the method includes: Scan the photovoltaic device to obtain its unique factory identification information. Scan the location markers at the installation site to obtain the physical installation location information of the photovoltaic equipment; Establish a mapping relationship between the factory-unique identification information and the physical installation location information; The mapping relationship is sent to the backend management system, which verifies the mapping relationship based on the preset logical address planning information. After the verification is successful, the system performs a remote batch address modification operation based on the extended Modbus protocol to obtain photovoltaic devices with the target logical address.

6. The method according to claim 5, characterized in that, After the step of sending the mapping relationship to the backend management system, the method further includes: Receive the address modification confirmation message returned by the photovoltaic device; The locally maintained device address mapping relationship is updated based on the confirmation message, and the modification status and modification time of each device are recorded.

7. An address management method based on the Modbus protocol, characterized in that, The method is applied to photovoltaic equipment, wherein the photovoltaic equipment is communicatively connected to a back-end management system and a mobile terminal, respectively; the method includes: Receive and respond to the scanning operation of the mobile terminal, and provide the factory-unique identification information stored in the photovoltaic device; Receive custom function code messages based on the extended Modbus protocol sent by the back-end management system; Parse the custom function code message to identify its message type; If the message is identified as a test communication message, and the old address in the test communication message is consistent with its current address, then the test communication message is replied to the background management system as is to confirm that the communication status is good.

8. The method according to claim 7, characterized in that, After parsing the custom function code message and identifying its message type, the method further includes: If the message is identified as an address modification message, and the old address in the address modification message is consistent with its current address, then the new address in the message is extracted, the communication address is updated to the new address, and an address modification confirmation message is returned to the backend management system.

9. An address management system based on the Modbus protocol, characterized in that, include: A mobile terminal is used to scan the QR code on the photovoltaic equipment to obtain the factory unique identification information, scan the location mark on the installation location to obtain the physical installation location information, establish a mapping relationship between the factory unique identification information and the physical installation location information, and send the mapping relationship to the background management system. The background management system is communicatively connected to the mobile terminal and multiple photovoltaic devices. It is used to receive the mapping relationship, verify the mapping relationship based on preset logical address planning information, and if the verification is successful, send test communication messages and address modification messages to the photovoltaic devices through IC function codes based on the extended Modbus protocol to modify the device addresses in batches. The photovoltaic equipment has a factory address that is a preset unique number and supports the extended Modbus protocol based on the IC function code. It is used to respond to the scanning operation of the mobile terminal to provide the factory unique identification information, and to receive and respond to the test communication messages and address modification messages sent by the background management system. During test communication, it replies with messages as is, and when the address is modified, it updates its own address and returns confirmation information.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the address management method based on the Modbus protocol as described in any one of claims 1 to 8.

Images