A serial communication method based on data collection of a solar monitoring system

Abstract

The application discloses a serial communication method based on data collection of a solar monitoring system, which comprises that a Master (communication management machine) sends a calling time synchronization command, and a Slave (intelligent unit) does not need to respond; the serial communication method based on data collection of the solar monitoring system solves the problems of long data updating interval and information check encryption of the solar monitoring, has unique function codes for different types of equipment, and according to the function codes and communication addresses of different Slaves, the device type and position of data are quickly searched out through message information, the communication ports and communication cable consumption of the Master of each square matrix in a photovoltaic area of a solar power station are saved, any topological wiring is supported, the laying difficulty and engineering quantity of communication cables are reduced, the compatibility intercommunication between intelligent devices of different manufacturers and different types of intelligent devices is realized, and the problems of limited communication device quantity and address in one communication protocol program of different intelligent unit equipment are solved.

Description

Technical Field

[0001] This invention belongs to the field of communication technology for solar energy monitoring systems, and specifically relates to a serial communication method based on data acquisition in a solar energy monitoring system. Background Technology

[0002] The solar monitoring system in a solar power plant's photovoltaic (PV) area primarily collects solar monitoring data from inverters, transformer substations, and combiner boxes. Currently, each array in a traditional solar power plant has an installed capacity of approximately 3MW. Each array is equipped with one transformer substation, one to two inverters, and a dozen or so combiner boxes, among other intelligent units. Each array has a Master (communication management unit) that communicates with each Slave (intelligent unit). Communication is based on a daisy-chain communication mode using the RS485 bus in the MODBUS serial communication protocol. All RS485 loop communication follows a master / slave model, where the master sends a request first, and the slave sends a response after receiving the request. In the traditional master / slave model, the master can only send a request to one slave at a time. Only after the slave responds can the master access the next slave. Each slave is accessed by the master only once, resulting in a long cycle and a long interval between solar monitoring data updates.

[0003] Meanwhile, in conventional communication designs, intelligent units (slaves) such as transformer substation monitoring and control, inverters, and combiner boxes must each be equipped with an RS485 port for the Master. Since there are a large number of combiner box devices, they generally occupy 2-3 RS485 communication ports. Thus, a single array in a solar power plant's photovoltaic area requires 4-5 RS485 communication ports for the Master, resulting in a significant number of Master communication ports being occupied per array. Furthermore, the communication cable connection between the transformer substation monitoring and control, inverters, combiner boxes, and other slaves and the Master must be an independent RS485 loop, requiring a separate communication cable for each loop. This leads to a large amount of communication cable usage per array, increasing the difficulty and workload of communication cable laying.

[0004] Traditional Slave communication addresses: a maximum of 255 Slaves can be set up in a single communication protocol program for a single type of intelligent unit device. The number of Slave communication devices and addresses are limited.

[0005] In addition to the problems mentioned above, the traditional method of checking communication message information between the master station and the slave station uses CRC16 cyclic redundancy check or parity check, which cannot achieve secure encryption of message information while performing the check. Summary of the Invention

[0006] The purpose of this invention is to address the problems existing in the prior art. This invention discloses a serial communication method based on data acquisition of a solar energy monitoring system, which solves the problems of long update intervals and information verification and encryption in solar energy monitoring. It achieves compatibility and interoperability between intelligent devices from different manufacturers and of different types, while saving the communication ports and communication cables occupied by the Master of each array in the photovoltaic area of ​​the solar power plant. It supports arbitrary topology wiring, reduces the difficulty and workload of laying communication cables, and solves the problem of limited communication device quantity and address for different intelligent unit devices in a single communication protocol program.

[0007] To achieve the above objectives, the present invention provides the following technical solution: a serial communication method based on data acquisition of a solar monitoring system, wherein the Master (communication management unit) sends a time synchronization command, and the Slave (intelligent unit) does not need to respond;

[0008] The Master sends a general call command, and the Slave at the first address responds to the general call command;

[0009] If, during the master-summoning process, the slave receives a remote control command from the master, it will execute the command first. The master sends a remote control selection command, and the slave responds with a verification confirmation. The master sends a remote control execution command, and the slave responds with a remote control execution completion. When the remote control ends, the master sends a master-summoning resumption command, and the next slave responds to the master-summoning command.

[0010] If the Slave receives a setting modification command from the Master, the Slave executes the setting modification command first; the Master sends a setting modification instruction, and the Slave sends a setting modification confirmation response; the Slave finishes modifying the setting, the Master sends a general call recovery command, and the Slave responds to the general call command at the next address;

[0011] After each slave responds to the general call command, it first checks whether there is a remote control or fixed value modification command. If there is no priority command, it continues to the next slave address to respond to the general call command.

[0012] If the slave does not respond to the master's remote control or setting modification command, the master sends a remote control failure or setting modification failure event alarm.

[0013] After a round of Master-Slave mobilization and response, the Master sends a channel acknowledgment request to the first unresponsive Slave. The Slave replies with a channel anomaly acknowledgment. If there is no reply, the Master issues a communication anomaly alarm. After the Master completes all communication anomaly channel acknowledgment responses, it proceeds to the next round of mobilization or the mobilization ends.

[0014] In some embodiments, before the Master invokes the data information of the Slave, the following steps are also included: the Master sends a clock synchronization command to the Slave to make the time of all Slaves consistent with that of the Master.

[0015] In some embodiments, the Slave calculates the transmission time based on the Slave address that currently responds correctly and its own address, where: (Slave address to be sent - Slave address currently sending data) × fixed delay between data transmissions.

[0016] In some embodiments, the Master can quickly identify which specific Slave the received data comes from. In all Slaves of the solar power plant, any message sent by any Slave to the Master carries a unique identifier, namely the Slave address and function code.

[0017] In some embodiments, the following verification method is used to verify the communication message information between the Master and the Slave:

[0018] Step 1: Excluding the message information, perform cumulative calculations in groups of 4 bytes. If the cumulative sum exceeds FFH, update the sum by subtracting an integer multiple of FFH and taking the positive remainder. If the cumulative sum does not exceed FFH, leave the sum unchanged. If the last group of the message information is less than 4 bytes, supplement it to 4 bytes. The supplemented bytes are Sac codes, which are modifiable encryption bytes. In one embodiment of the present invention, there are 3 Sac code values: S1 is 05H, S2 is 3CH, and S3 is A0H.

[0019] Step 2: Repeat the above calculation on the accumulated sum, grouping it into 4-byte units from left to right. If the last unit has less than 4 bytes, add Sac code. Continue this process until only 2 bytes remain in each group. The first byte is used as the high byte of the Sacbus checksum, and the second byte is used as the low byte. If there are 3 bytes remaining, the first 2 bytes are summed. If there are 4 bytes remaining, the sums of the first 2 bytes and the last 2 bytes are calculated separately.

[0020] The present invention has at least the following beneficial effects:

[0021] This invention discloses a serial communication method based on data acquisition from a solar energy monitoring system. It solves the problems of long update intervals and information verification encryption in solar energy monitoring. Different types of devices have unique function codes. Based on the function codes and communication addresses of different slaves, the device type and location from which the data originated can be quickly retrieved through message information. Simultaneously, it saves communication ports and cables occupied by the Master in each array of a solar power plant's photovoltaic area. It supports arbitrary topology wiring, reducing the difficulty and workload of communication cable laying. It achieves compatibility and interoperability between intelligent devices from different manufacturers and of different types, while also solving the problem of limited communication device numbers and addresses for different intelligent unit devices within a single communication protocol program. Attached Figure Description

[0022] Figure 1 This is a flowchart illustrating the serial communication method for data acquisition based on a solar energy monitoring system as described in this invention.

[0023] Figure 2 This is a schematic diagram of the serial communication network topology for data acquisition based on a solar energy monitoring system as described in this invention;

[0024] Figure 3 This is a comparison diagram of the Sacbus topology based on solar energy monitoring system data acquisition and the traditional serial communication network topology described in this invention;

[0025] Figure 4 This is a schematic diagram of the Master module for data acquisition based on a solar energy monitoring system as described in this invention.

[0026] Figure 5 This is a schematic diagram of the information verification calculation steps of the serial communication method based on data acquisition from a solar energy monitoring system as described in this invention. Detailed Implementation

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

[0028] The serial communication method based on data acquisition of a solar monitoring system described in this invention adopts a Master / Slave mode: the Master is the master station, which in this invention is the Master (communication management machine) of each array in the photovoltaic area of ​​the solar power plant, and sends request messages; the Slave is the slave station, which in this invention is the Slave of each array in the photovoltaic area of ​​the solar power plant (including transformer substation monitoring and control, inverters and combiner boxes, etc.). After receiving the Master's general call command, each Slave responds to the Master's general call according to the transmit and receive strategy. Specifically, messages sent from the Master to the Slave and messages sent from the Slave to the Master have a fixed format. In this fixed format, the last two bytes of the message are a checksum, which is defined as a Sacbus checksum in this invention. The content of the message excluding the checksum is the message body. When the Slave receives a message sent by the Master that does not conform to the fixed format or does not meet the checksum, it means that the message sent by the Master to the Slave is invalid, and the Slave will not process or respond to the message. Similarly, when the Master receives a message sent by the Slave that does not conform to the fixed format or does not meet the checksum, it means that the message sent by the Slave to the Master is invalid, and the Master will not process or respond to the message.

[0029] The message verification uses Sacbus's built-in checksum, which is used for data encryption and error checking during transmission and reception. The message satisfies the checksum if the calculated Sacbus checksum matches the built-in Sacbus checksum in the message; otherwise, it fails the checksum. The process for calculating the Sacbus checksum from the message is as follows:

[0030] Step 1: Divide the body of the message into groups of 4 bytes and determine whether the body can be divided into more than one group.

[0031] If the message cannot be divided into more than one group, it means that the message body is less than or equal to 4 bytes, usually 3 or 4 bytes. If the message body is 3 bytes, the first 2 bytes are summed. If the sum exceeds FFH, the value is updated to the smallest positive remainder after subtracting an integer multiple of FFH. If the sum does not exceed FFH, the value remains unchanged. The updated sum of the last 2 bytes is used as the high byte of the Sacbus checksum, and the 3rd byte of the message body is used as the low byte of the Sacbus checksum. If the message body is 4 bytes, the sum of the first 2 bytes and the last 2 bytes are calculated separately. If the sum exceeds FFH, the value is updated to the smallest positive remainder after subtracting an integer multiple of FFH. If the sum does not exceed FFH, the value remains unchanged. The sum of the last 2 bytes is used as the high byte of the Sacbus checksum, and the sum of the last 2 bytes is used as the low byte of the Sacbus checksum.

[0032] If the data can be divided into more than one group of units, and the last group of units is less than 4 bytes, then it is padded to 4 bytes. Then, each group of units is accumulated. If the accumulated value exceeds FFH, then the value is updated to the smallest positive remainder after subtracting an integer multiple of FFH. If the accumulated value does not exceed FFH, then the value remains unchanged, and the process proceeds to the second step.

[0033] The supplemented bytes are Sac codes, which are modifiable encrypted bytes. The supplementation of Sac codes must be in a preset order. In one embodiment of the present invention, there are three Sac codes: S1 is 05H, S2 is 3CH, and S3 is A0H. The supplementation of Sac codes must be in the order of S1, S2, and S3. That is, if one byte is missing, S1 is supplemented; if two bytes are missing, S1 and S2 are supplemented in sequence; and if three bytes are missing, S1, S2, and S3 are supplemented in sequence.

[0034] Step 2: For several accumulated values, repeat the calculation process in Step 1 until only 2 bytes remain. The first byte is used as the high byte of the Sacbus checksum, and the second byte is used as the low byte of the Sacbus checksum.

[0035] Taking the 21-byte body of the message as an example, the Sacbus checksum encryption calculation steps are as follows: Figure 5 As shown:

[0036] Step 1: Divide the 21-byte text into 6 groups of 4 bytes each. Since the last group contains only 1 byte, add Sac codes S1, S2, and S3 in sequence. Calculate the cumulative value by summing the bytes in each group. Compare the cumulative value of each group with FFH. If the cumulative value exceeds FFH, update it to the smallest positive remainder after subtracting an integer multiple of FFH. If the cumulative value does not exceed FFH, it remains unchanged. This yields a cumulative value of 6 bytes, which leads to Step 2.

[0037] Step 2: Divide the 6-byte accumulated value into two groups of 4 bytes each. Since the second group only has 2 bytes, Sac codes S1 and S2 are added sequentially. Calculate the accumulated value by summing the bytes in each group. Compare the accumulated value of each group with FFH. If the accumulated value exceeds FFH, update it to the smallest positive remainder after subtracting an integer multiple of FFH. If the accumulated value does not exceed FFH, it remains unchanged. Thus, a 2-byte accumulated value can be obtained. The accumulated value of the first byte is used as the high byte of the Sacbus check code, and the accumulated value of the second byte is used as the low byte of the Sacbus check code.

[0038] In this invention, the Master of each array in the photovoltaic area of ​​the solar power plant is connected to a ring network switch via an RJ45 port, and the ring network switch is then connected to an Ethernet network. Within each array, the cable connections between the Master and Slaves use a daisy-chain RS485 bus connection. The RS485 communication port configured on the Master differs from the traditional RS485 serial port; it incorporates a Powerbus bus control unit module, allowing connection to any Slave and supporting arbitrary topology cabling. There are no requirements regarding the number or order of Slaves connected. This network topology simplifies the communication network structure between the Slaves and Master, saving a significant amount of communication cable. Taking array 1 as an example, the slave in array 1 includes one transformer substation monitoring and control unit, two inverters (inverter 1 and inverter 2), and 15 combiner boxes (combine box 1, combiner box 2, ..., combiner box 15). In the traditional communication network topology, the transformer substation monitoring and control unit is connected to the Master's RS485 serial port COM1, inverter 1 is connected to the Master's RS485 serial port COM2, inverter 2 is connected to inverter 1, combiner box 1 is connected to the Master's RS485 serial port COM3, combiner box 2 is connected to combiner box 1, combiner box 3 is connected to combiner box 2, and combiner box 4 is connected to combiner box 3. Combiner box 5 is connected to combiner box 4; combiner box 6 is connected to the Master's RS485 serial port COM4; combiner box 7 is connected to combiner box 6; combiner box 8 is connected to combiner box 7; combiner box 9 is connected to combiner box 8; combiner box 10 is connected to combiner box 9; combiner box 11 is connected to the Master's RS485 serial port COM5; combiner box 12 is connected to combiner box 11; combiner box 13 is connected to combiner box 12; combiner box 14 is connected to combiner box 13; combiner box 15 is connected to combiner box 14. In one embodiment of the invention, the transformer substation monitoring and control is connected to the Master's RS485 serial port COM1, and the others are connected according to... Figure 3 The wiring diagram below shows the topology of the Sacbus communication network.

[0039] To facilitate the Master's rapid identification of which specific Slave the received data originated from, each Slave in the solar power plant carries a unique feature code, or function code, in every message sent from the Slave to the Master. In one embodiment of this invention, the transformer substation monitoring and control unit, inverter, combiner box, etc., each have their own unique function code.

[0040] The address range of the transformer substation monitoring and control is 0x01-0xFF, and the function code range is 0x34-0x66. It can quickly identify up to 13005 Slaves (transformer substation monitoring and control).

[0041] The inverter's address range is 0x01-0xFF, and its function code range is 0x67-0x99. It can quickly identify up to 13,005 Slaves (inverters).

[0042] The address range of the combiner box is 0x01-0xFF, and the function code range is 0x9A-0xCC. It can quickly identify up to 13005 Slaves (combine boxes).

[0043] The address range of other slaves is 0x01-0xFF, and the function code range is 0xCD-0xFF. Up to 13005 slaves can be quickly identified.

[0044] Any message sent from any Slave to the Master can locate the corresponding Slave in the solar power plant based on its address and function code. This simplifies data processing and Slave location for both the backend monitoring system and the Master, and solves the problem of limited Slave communication addresses. For example, with traditional Slave communication addresses, a maximum of 255 Slaves of a single type of intelligent unit device can be configured in a single communication protocol program. This invention, however, can configure 13,005 Slaves.

[0045] Based on the above-mentioned conditions, the serial communication method for data acquisition based on a solar energy monitoring system according to the present invention includes the following steps:

[0046] Step S1: The Master sends a clock synchronization command to the Slave. This command means the Master sends its time to all Slaves, ensuring all Slaves' times are consistent with the Master's. This is similar to time synchronization and prevents the receipt of incorrect or outdated information later. When a Slave receives the Master's time, it checks if its own time matches the Master's. If not, it adjusts its own time to match the Master's.

[0047] The fixed format requirements for clock synchronization command messages are shown in Table 1 below, and include the following bytes in sequence: message type identifier, function code, transmission reason, common address, information address, millisecond low byte, millisecond high byte, minute, hour, day, month, year, check high byte, and check low byte.

[0048] Table 1

[0049]

[0050]

[0051] The message category identifier is a fixed identifier, which allows the slave to identify whether the message is a clock synchronization command. In one embodiment of the present invention, the message category identifier for the clock synchronization command is 01H; the message category identifier for the general call command is 02H; the message category identifier for the remote selection / remote execution command is 1AH; and the message category identifier for the setting modification command is 1BH.

[0052] The main reason for transmission is to distinguish messages with different content, so that the receiver can easily parse the received messages. In one embodiment of the present invention:

[0053] The reason for transmitting the clock synchronization command is 01H;

[0054] The reason for the transmission of the Master call command is 02H;

[0055] The reason for the transmission of the Master's general call command is A2H;

[0056] The transmission reason for the message from the Master modifying the Slave's settings is 03H;

[0057] The reason for the transmission of the Slave's response message to the Master's setting modification is 04H;

[0058] The transmission reason for the Master remote control selection command is 05H;

[0059] The Slave responds to the Master's remote control selection command transmission reason 06H;

[0060] The transmission reason for the Master remote control execution command is 07H;

[0061] The Slave responds to the Master's remote control execution command transmission reason 08H;

[0062] The transmission reason for both the Master channel acknowledgment request and the Slave channel acknowledgment response is 0FH;

[0063] The public address is mainly used to distinguish different format messages, making it easier for the receiver to parse the message after receiving it. For example, a message with a public address is applicable to all data receiving devices, i.e., all Slaves. In this invention, the public address of the clock synchronization command is preset, and the function code of the clock synchronization command is also preset. Through the numerical mapping of the transmission reason, function code and public address, the Slave can determine that the message is a clock synchronization command.

[0064] The information address is mainly used to distinguish messages of different formats, so that the receiver can parse the message after receiving it. This line is only for the purpose of format integrity.

[0065] The low byte of milliseconds, the high byte of milliseconds, the minute, the hour, the day, the month, and the year are used to represent the time of the message;

[0066] The high byte and low byte are used to ensure the accuracy of the received message.

[0067] In one embodiment of the present invention, the message sent by the Master to transmit the clock synchronization command is as follows:

[0068] 01 02 01 01 01AD 39 08 0E 0B 02 16F4 31

[0069] Among them: Message type identifier 01H indicates that the message is a clock synchronization command; transmission reason 01H indicates that the message is a clock synchronization command; function code 02H and common address 01H, after numerical mapping, indicate that the message is a clock synchronization command; information address 01H has no practical meaning; the Master requests time synchronization of all Slaves on the RS485 bus; message time AD 39080E 0B 02 16 is 14:08:14765 milliseconds on February 11, 2022; Sacbus checksum is F4 31H, with the high byte first and the low byte last.

[0070] Step S2: After time synchronization is completed, the Master sends a general call command, and the Slave at the first address responds to the general call command;

[0071] If, during the master-summoning process, the slave receives a remote control command from the master, it will execute the command first. When the master sends a remote control selection command, the slave will respond with a remote control selection verification confirmation. When the master sends a remote control execution command, the slave will respond with a remote control execution completion. When the remote control ends, the master will send a master-summoning resumption command, and the next slave will respond to the master-summoning command.

[0072] If the Slave receives a setting modification command from the Master, the Slave executes the setting modification command first; the Master sends a setting modification instruction, and the Slave sends a setting modification confirmation response; the Slave finishes modifying the setting, the Master sends a general call recovery command, and the Slave responds to the general call command at the next address;

[0073] After each slave responds to the general call command, it first checks whether there is a remote control or fixed value modification command. If there is no priority command, it continues to the next slave address to respond to the general call command.

[0074] If the slave does not respond to the master's remote control or setting modification command, the master sends a remote control failure or setting modification failure event alarm.

[0075] After a round of Master-Slave mobilization and response, the Master sends a channel acknowledgment request to the first unresponsive Slave. The Slave replies with a channel anomaly acknowledgment. If there is no reply, the Master issues a communication anomaly alarm. After the Master completes all communication anomaly channel acknowledgment responses, it proceeds to the next round of mobilization or the mobilization ends.

[0076] In this step, after the Master starts up or resets, the Master sends a general call command. After receiving the general call command, the Slave can send monitoring data (including telemetry, telesignaling, telepulse, etc.) to the Master in response to the request. The Slave automatically sends data to the Master in address order. There is a fixed delay between the two Slaves, which is preset.

[0077] Slaves proactively send data to the Master in address order. Each slave detects the address of the slave currently transmitting data on the RS485 bus, meaning it can receive messages on the RS485 bus and parses out the address of the slave that sent the message. It then calculates its own transmission time and sends the data with the corresponding delay. The transmission time is calculated as: (Slave address to be transmitted - Slave address currently transmitting data) × fixed delay between data transmissions. Each time a new slave transmits data on the RS485 bus, the other slaves recalculate their transmission times. After the Master initializes and calls the Master, each slave on the bus does not interrupt its response due to whether the slave at the previous address has successfully transmitted data; it responds according to its latest calculated transmission time.

[0078] This method improves the communication efficiency of solar power plant sites, shortens the data collection and transmission time, and allows monitoring data to be refreshed faster.

[0079] The fixed format of the Master general call message is shown in Table 2 below, which includes the following bytes in order: message type identifier, function code, transmission reason, common address, information address, high byte of checksum and low byte of checksum.

[0080] Table 2

[0081] Function code 01 Transmission reason 02 Public Address 01 Information address 01 Verify high byte 06 Check the low byte CA

[0082] The function code for Master's general summon is 01H;

[0083] In one embodiment of the present invention, the message containing the data information for the Master to call upon the Slave is as follows:

[0084] 02 01 02 01 01 06CA

[0085] Among them: the transmission reason 02H indicates that the message is a Master general call, the public address and information address are 01H; the Sacbus check code is 06CAH, with the high byte first and the low byte last.

[0086] The fixed format of the Slave's response message to the Master's call is shown in Table 3 below, which includes the following bytes in sequence: Slave address, function code, transmission reason, data length, telemetry data, teleindication data, telepulse data, alarm data, high byte of checksum, and low byte of checksum.

[0087] Table 3

[0088]

[0089]

[0090] The communication address refers to the address of the Slave itself;

[0091] The function code represents the function code of the Slave itself;

[0092] Data length refers to the total length of telemetry data, teleindication data, telepulse data, and alarm data;

[0093] Telemetry data represents real-time parameters of the power system operation monitored by the Slave;

[0094] Remote signaling data represents relay signals such as switch position, input signal, high oil temperature, and abnormal pressure monitored by the Slave;

[0095] Remote pulse data represents the electricity consumption value monitored by the Slave, including forward electricity consumption, reverse electricity consumption, total electricity consumption, peak and valley electricity consumption, etc.

[0096] Alarm data indicates overcurrent protection action signals, undervoltage protection action signals, grounding protection action signals, etc., monitored by the Slave.

[0097] The positions and data segments of telemetry data, teleindication data, telepulse data, and alarm data in the message are fixed and preset.

[0098] In one embodiment of the present invention, the message sent by the Slave in response to the Master's call is as follows:

[0099] 02 34 02 42 17 70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000 13 88 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000 00 00 00 00 00 00 00 00 00 00F9 5F 00 00 00 00 00 00 00 00F8 64

[0100] Wherein: The transmission reason 02H indicates that this message is a Slave reply to the Master's call; the Slave's response to the Master's request data, the Slave address is 02H, and the function code is 34H (in this embodiment, it is a transformer substation monitoring and control); 42H is the data length, i.e., there are 66 bytes of monitoring data; 17 70 0 ... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00H represents remote pulse value data; F9 5F 00 00 00 00 0000 00 00 00H represents alarm data; the Sacbus checksum is F8 64H, with the most significant byte first and the least significant byte last.

[0101] Step S3: After each Slave responds to the general call command, it first checks whether there is a remote control or fixed value modification command. If there is a priority command, the remote control or fixed value modification command is executed first.

[0102] The fixed format of the Master remote selection command message is shown in Table 4 below, which includes the following bytes in sequence: message type identifier, function code, transmission reason, common address, Slave address, high byte of checksum and low byte of checksum.

[0103] Table 4

[0104] Function code 34 Transmission reason 05 Public Address 01 Slave address 01 Verify high byte 54 Check the low byte E2

[0105] The function code for the transformer substation monitoring and control is 34H;

[0106] Slave address 01H is the communication address for the Master to remotely select the Slave;

[0107] In one embodiment of the present invention, the message of the Master remote control Slave selection command is as follows:

[0108] 1A 34 05 01 01 54E2

[0109] Wherein: Transmission reason 05H indicates the Master remote control selection command, the common address is 01H; the Sacbus checksum is 54E2H, with the high byte first and the low byte last.

[0110] The Master sends a remote selection command, and the Slave responds to the remote selection command.

[0111] The fixed format of the remote selection command message sent by the Slave to the Master is shown in Table 5 below, which includes the following bytes in order: message type identifier, function code, transmission reason, common address, Slave address, high byte of checksum and low byte of checksum.

[0112] Table 5

[0113] Function code 34 Transmission reason 06 Public Address 01 Slave address 01 Verify high byte 55 Check the low byte E2

[0114] The function code for the transformer substation monitoring and control is 34H;

[0115] Slave address 01H is the communication address for the Master to remotely select the Slave;

[0116] In one embodiment of the present invention, the message sent by the Slave in response to the Master's remote control selection command is as follows:

[0117] 1A 34 06 01 01 55E2

[0118] Among them: transmission reason 06H indicates that the slave is responding to the master's remote control selection command, the common address is 01H; the Sacbus checksum is 55E2H, with the high byte first and the low byte last.

[0119] Once the slave correctly responds to the master's remote selection command, the master sends a remote execution command to the slave.

[0120] The fixed format of the message from Master to Slave to send remote execution commands is shown in Table 6 below, which includes the following bytes in sequence: message type identifier, function code, transmission reason, common address, Slave address, information element (control), high byte of checksum and low byte of checksum.

[0121] Table 6

[0122] Function code 34 Transmission reason 07 Public Address 01 Slave address 01 Information element (control) FF 00 Verify high byte 56 Check the low byte 06

[0123] The function code for the transformer substation monitoring and control is 34H;

[0124] Slave address 01H is the communication address for the Master to remotely execute the Slave;

[0125] Information element FF 00H represents control combination, and control separation is represented by 00 00H;

[0126] In one embodiment of the present invention, the message sent by the Master to remotely control the Slave to execute the control command is:

[0127] 1A 34 07 01 01FF 00 56 06

[0128] Among them: transmission reason 07H indicates that the Master remotely executes the command, the common address is 01H; the Slave address is 01H; the Sacbus checksum is 56 06H, with the high byte first and the low byte last.

[0129] The fixed format of the message from the Slave to the Master in response to remote execution commands is shown in Table 7 below. It includes the following bytes in sequence: message type identifier, function code, transmission reason, common address, Slave address, information element (control), high byte of checksum and low byte of checksum.

[0130] Table 7

[0131]

[0132]

[0133] The function code for the transformer substation monitoring and control is 34H;

[0134] Slave address 01H is the communication address for the Master to remotely select the Slave;

[0135] Information element FF 00H represents control combination, and control separation is represented by 00 00H;

[0136] In one embodiment of the present invention, the message sent by the Slave in response to the Master's remote control execution command is as follows:

[0137] 1A 34 08 01 01FF 00 57 06

[0138] Among them: transmission reason 08H indicates that the slave is responding to the master's remote control execution command, the common address and slave address are 01H; the Sacbus checksum is 57 06H, with the high byte first and the low byte last.

[0139] The fixed format of the Master's instruction to modify the Slave's setpoint is shown in Table 8 below, which includes the following bytes in sequence: message type identifier, function code, transmission reason, common address, Slave address, data address high byte, data address low byte, setpoint high byte, setpoint low byte, checksum high byte, and checksum low byte.

[0140] Table 8

[0141] Function code 34 Transmission reason 03 Public Address 01 Slave address 03 Data address high bit 10 Data address low bits 01 High value 00 Low value 82 Verify high byte 67 Check the low byte 64

[0142] The function code for the transformer substation monitoring and control is 34H;

[0143] Slave address 03H is the Slave communication address whose value has been modified.

[0144] In one embodiment of the present invention, the message used by the Master to modify the Slave setting is:

[0145] 1B 34 03 01 03 10 01 00 82 67 64

[0146] Among them: transmission reason 03H indicates that the Master modifies the Slave setting, the common address is 01H; the Slave address is 03H; the data address is 10 01H, the address information is transformer over-temperature alarm; the setting value is 00 82H, which is 130D in decimal, that is, the transformer over-temperature alarm temperature is set to 130 degrees; the Sacbus check code is 67 64H, with the high byte first and the low byte last.

[0147] The fixed format of the Slave response message to the Master's setting modification command is shown in Table 9 below, which includes the following bytes in sequence: message type identifier, function code, transmission reason, common address, Slave address, data address high byte, data address low byte, setting high byte, setting low byte, checksum high byte, and checksum low byte.

[0148] Table 9

[0149] Function code 34 Transmission reason 04 Public Address 01 Slave address 03 Data address high bit 10 Data address low bits 01 High value 00 Low value 82 Verify high byte 68 Check the low byte 64

[0150] The function code for the transformer substation monitoring and control is 34H;

[0151] Slave address 03H is the Slave communication address whose value has been modified.

[0152] In one embodiment of the present invention, the Slave responds to the Master's message regarding the modification of a set value as follows:

[0153] 1B 34 04 01 03 10 01 00 82 68 64

[0154] Among them: transmission reason 04H indicates that the Slave responds to the Master's message to modify the set value, the common address is 01H; the Slave address is 03H; the data address is 10 01H, and the address information is transformer over-temperature alarm; the set value is 00 82H, which is 130D in decimal, that is, the transformer over-temperature alarm temperature is set to 130 degrees; the Sacbus check code is 68 64H, with the high byte first and the low byte last.

[0155] The fixed format of the Master's message for sending a general call recovery command is shown in Table 10 below, which includes the following bytes in sequence: message type identifier, function code, transmission reason, Master general call start function code, Master general call start address, high byte of checksum and low byte of checksum.

[0156] Table 10

[0157] Function code 01 Transmission reason A2 Master General Summoning Starter Code 34 Master's General Recruitment Starting Address 03 Verify high byte D9 Check the low byte E4

[0158] The function code for Master's general summon is 01H;

[0159] In one embodiment of the present invention, the message used by the Master to restore the data information of the Slave is as follows:

[0160] 02 01A2 34 03D9 E4

[0161] Among them: the transmission reason A2H indicates that the message is for Master to resume general recall. The Master general recall start function code is 34, which is the function code of the last general recall of Slave. The Master general recall start address is 03H; the Sacbus check code is D9 E4H, with the high byte first and the low byte last.

[0162] Step S4: After the last address Slave responds to the end of the general call (including correct and incorrect responses from the Slave), the Master sends a channel confirmation request to the Slave that did not respond correctly to the call request. If the Slave does not respond to the channel confirmation request, the Master issues a communication abnormality alarm and determines whether to proceed with the next round of data general call. If the next round of data general call is to be conducted, the Master resends the general call request; otherwise, the Master ends the data call.

[0163] The fixed format of the message from the Master to the Slave to send a channel acknowledgment request is shown in Table 11 below, which includes the following bytes in sequence: Slave address, function code, transmission reason, high byte of start address, low byte of start address, high byte of data, low byte of data, high byte of checksum, and low byte of checksum.

[0164] Table 11

[0165]

[0166]

[0167] The Slave address represents the Slave address from which the Master sends the channel acknowledgment request;

[0168] The function code represents the Slave function code used by the Master to send a channel acknowledgment request;

[0169] The high and low bits of the starting address, and the high and low bits of the data, are the program-defined message format and content in the channel acknowledgment request message to ensure message integrity.

[0170] In one embodiment of the present invention, the message sent by the Master to the Slave as a channel acknowledgment request is:

[0171] 01 34 0F 10 02 00AA 54B1

[0172] Among them: the transmission reason 0FH indicates that the message is a Master channel acknowledgment request; the Master sends a channel acknowledgment request to the Slave, the Slave address is 01H, and the function code is 34H; the register address 10 02H and the register data 00AAH are fixed message format and content; the Sacbus check code is 54B1H, with the high byte first and the low byte last.

[0173] The fixed format of the Slave channel acknowledgment response message is shown in Table 12 below, which includes the following bytes in sequence: Slave address, function code, transmission reason, acknowledgment code, high byte of checksum, and low byte of checksum.

[0174] Table 12

[0175] Function code 34 Transmission reason 0F Confirmation code AA Verify high byte 35 Check the low byte B9

[0176] The communication address represents the address of the slave that confirmed the response;

[0177] The function code indicates the function code of the slave that confirmed the response;

[0178] The acknowledgment code has a fixed format. If the slave confirms the response (i.e., replies with channel confirmation), it replies with an acknowledgment code. In one embodiment of the present invention, the acknowledgment code is AAH.

[0179] In one embodiment of the present invention, the Slave channel acknowledgment response message is as follows:

[0180] 01 34 0F AA 35B9

[0181] Wherein: Transmission reason 0FH indicates that the message is a Slave channel acknowledgment response; the Slave responds to the Master's channel acknowledgment request, the Slave address is 01H, the function code is 34H; the acknowledgment code is AAH; the Sacbus checksum is 35B9H, with the high byte first and the low byte last.

[0182] like Figure 4 As shown, the Master of this invention includes a data interface unit (I / O circuit), a central processing unit (ADSP-2185M), a management and Ethernet communication unit (MON), a bus control unit (Powerbus), and a power control unit (ZYDY).

[0183] Supported serial interfaces include RS232 / RS485 with baud rates of 2400bps and 9600bps. Compatible communication protocols include Sacbus, Modbus, IEC103, and DL / T645. The primary communication medium is shielded twisted-pair cable. Data transmission modes include simplex, half-duplex, and full-duplex. The serial communication distance is approximately 2km.

[0184] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0185] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A serial communication method for data acquisition based on a solar energy monitoring system, characterized in that: The Master communication management unit sends a call time synchronization command, and the Slave intelligent unit does not need to respond; The Master communication management unit sends a general call command. The Slave intelligent unit at the first address responds to the general call command. The Slave intelligent unit calculates the transmission time based on the Slave address that has responded correctly and its own address. The formula for calculating the transmission time is: Transmission time = (Slave address to be sent - Slave address currently sending data) × fixed delay between data transmissions. If, during the general call process, the Slave intelligent unit receives a remote control command from the Master communication management unit, it will execute the remote control command first; the Master communication management unit sends a remote control selection command, and the Slave intelligent unit replies with a verification confirmation response; the Master communication management unit sends a remote control execution command, and the Slave intelligent unit replies with a remote control execution completion response; when the remote control ends, the Master communication management unit sends a general call resumption command, and the Slave intelligent unit at the next address responds to the general call command; If the Slave intelligent unit receives a setting modification command from the Master communication management unit, the Slave intelligent unit executes the setting modification command first; the Master communication management unit sends a setting modification instruction, and the Slave intelligent unit sends a setting modification confirmation response; after the Slave intelligent unit finishes the setting modification, the Master communication management unit sends a general call recovery command, and the Slave intelligent unit at the next address responds to the general call command; After each Slave smart unit responds to the master call command, it first checks whether there is a remote control or setting modification command. If there is no priority command, it continues to the next address Slave smart unit responding to the master call command. If the Slave intelligent unit does not respond to the Master communication management unit's remote control or setting modification command, the Master communication management unit sends a remote control failure or setting modification failure event alarm. After a round of master communication management machine's general call to slave intelligent units concludes and the slave intelligent units respond, the master communication management machine sends a channel acknowledgment request to the first unresponsive slave intelligent unit. The slave intelligent unit replies with a channel anomaly acknowledgment. If there is no reply, the master communication management machine issues a communication anomaly alarm. After the master communication management machine completes all communication anomaly channel acknowledgment responses, it proceeds to the next round of general call or the general call ends. The following verification method is used to verify the communication message information between the Master communication management unit and the Slave intelligent unit: Step 1: Excluding the message information, perform cumulative calculations in groups of 4 bytes. If the cumulative sum exceeds the hexadecimal number 0xFF, update the cumulative sum by subtracting an integer multiple of the hexadecimal number 0xFF and taking the positive remainder. If the cumulative sum does not exceed the hexadecimal number 0xFF, leave the cumulative sum unchanged. If the last group of the message information is less than 4 bytes, supplement it to 4 bytes. The supplemented bytes are Sac codes. Sac codes are modifiable encryption bytes. There are 3 Sac code values: S1 is 05H, S2 is 3CH, and S3 is A0H. The Sac code should be supplemented according to the following order: if one byte is missing, supplement S1; if two bytes are missing, supplement S1 and S2 in sequence; if three bytes are missing, supplement S1, S2, and S3 in sequence. Step 2: Repeat the above calculation on the accumulated sum, grouping it into 4-byte units from left to right. If the last unit group has less than 4 bytes, add Sac code. Continue this process until only 2 bytes remain in each group. The first byte is used as the high byte of the Sacbus checksum, and the second byte is used as the low byte. If there are 3 bytes remaining, the first 2 bytes are added together. If there are 4 bytes remaining, the first 2 bytes and the last 2 bytes are added together separately. Step 3: Compare the Sacbus checksum calculated from the message with the Sacbus checksum contained in the message. If the Sacbus checksum calculated from the message matches the Sacbus checksum contained in the message, the message satisfies the checksum; if the Sacbus checksum calculated from the message does not match the Sacbus checksum contained in the message, the message does not satisfy the checksum.

2. The serial communication method for data acquisition based on a solar energy monitoring system according to claim 1, characterized in that: Before the Master communication management unit summons data information from the Slave intelligent units, the following steps are also included: The Master communication management unit sends a clock synchronization command to the Slave intelligent units to make the time of all Slave intelligent units consistent with that of the Master communication management unit.

3. The serial communication method for data acquisition based on a solar energy monitoring system according to claim 1, characterized in that: The Master communication management unit quickly identifies which specific Slave intelligent unit the received data comes from. Among all the Slave intelligent units in the solar power plant, every message sent by any Slave intelligent unit to the Master communication management unit carries a unique feature code, namely the Slave address + function code.

Images