HPLC (High Performance Liquid Chromatography)-based power Internet of Things multi-scene data acquisition method

Abstract

The invention provides an electric power Internet of Things multi-scene data acquisition method based on HPLC, and belongs to the technical field of electric power communication. The technical problems of poor real-time performance, difficulty in access of various terminals and data uplink conflicts of a multi-STA concurrence mechanism in multi-scene data acquisition of the electric power Internet of Things based on HPLC (High Performance Liquid Chromatography) are solved. According to the technical scheme, the method comprises the following steps: S1, performing primary data pre-acquisition by terminal equipment; s2, a single-chip microcomputer in the II-type collector copies and stores the data collected by the terminal device through an RS-485 interface; s3, the server issues a data acquisition instruction; and S4, the single-chip microcomputer uploads the data stored last time to a server after IP protocol conversion and resource cross-layer allocation. The method has the beneficial effects that the real-time requirement of multi-scene data acquisition of the electric power Internet of Things is guaranteed to a great extent, and the uplink conflict of the multi-STA data is inhibited.

Description

Technical Field

[0001] The present invention relates to the field of power communication technology, and in particular to a multi-scenario data acquisition method for power Internet of Things based on HPLC. Background Art

[0002] With the widespread application of Internet of Things technology in power systems, the power industry has put forward higher requirements for the real-time and transmission of data. The data stream transmission of the power Internet of Things requires the support of efficient and reliable communication networks, such as optical fiber, 5G, high-speed power line carrier communication (HPLC), etc. Among them, HPLC is a power line communication technology, the full name is high-speed power line carrier or broadband power line carrier. It transmits data through power lines, realizes effective information communication between power companies and end users, and plays a very important role in the development of the power Internet of Things. Because HPLC technology has the advantages of no wiring, wide coverage, synchronization with power grid construction, and no need to add new communication cables, saving construction costs, it has been widely used in the field of power systems and electricity consumption information collection.

[0003] However, as smart grids develop towards diversification and intelligence, traditional electricity consumption information collection can no longer meet the needs. The rise of multi-scenario fusion applications has led to an increase in the number of carrier devices, diverse interface protocols, and complex device access and updates. At the same time, the dynamic topology, unstable loads, and electromagnetic interference of the power network bring challenges to the HPLC carrier communication concurrency mechanism, such as data conflicts under multiple STAs, which affect data transmission efficiency and accuracy, and are not conducive to the stable operation of smart grids and terminal equipment management.

[0004] In the existing power Internet of Things architecture, HPLC technology is mainly used to collect users' electricity consumption information, while data transmission for monitoring and surveillance scenarios requires the establishment of a wireless transmission system. This dual-mode architecture will lead to high complexity of the entire system and difficulty in data coordination.

[0005] The traditional HPLC electricity consumption information collection method has poor real-time performance, and most of the data collection is non-real-time. The current collection scheme can only collect frozen data for 15 minutes at the fastest, which cannot well support the development of new power Internet of Things business. Summary of the invention

[0006] The purpose of the present invention is to provide a multi-scenario data collection method for the power Internet of Things based on HPLC, aiming to solve the problems faced by multi-scenario data collection in the power Internet of Things, such as poor real-time performance, difficulty in multi-terminal access, and data uplink conflicts under a concurrent mechanism.

[0007] In order to achieve the above-mentioned invention object, the technical solution adopted by the present invention is specifically: a multi-scenario data acquisition method of the power Internet of Things based on HPLC, the technical solution is implemented based on the power Internet of Things system, the power Internet of Things system includes a server, a management device, a collection device and a terminal device, the collection device includes a single-chip microcomputer with storage and control functions, the terminal device includes an electric meter, and various sensor monitoring devices for monitoring and surveillance scenes, and the data acquisition method includes the following steps:

[0008] S1: The terminal device first performs data pre-collection, including different protocol data collected by the electricity meter and various sensors;

[0009] S2: The microcontroller in the Type II collector transcribes and stores the data collected by the terminal device through the RS-485 interface;

[0010] S3: The server issues data collection instructions, which are converted by the microcontroller protocol and sent to the terminal device;

[0011] S4: The single chip microcomputer uploads the last stored data to the server after IP protocol conversion and cross-layer resource allocation, and the terminal device continues to collect data, repeating the above steps S1 to S4.

[0012] Furthermore, the step S1 includes the following steps:

[0013] S1.1. The terminal device starts up, loads relevant drivers and configuration files, ensures the normal operation of its own functional modules, and performs self-tests on the hardware interfaces, including checking whether the communication ports connected to the meter and sensor, such as the RS-485 interface and communication module, are operating normally and confirming that there are no faults or damage.

[0014] S1.2. Establish a communication link with the meter by identifying the meter's communication protocol, such as the specific meter protocol under the RS-485 communication protocol. Send a data request instruction to the meter. The instruction content is formulated according to the meter protocol, covering acquisition requests for different data types such as voltage, current, power, and electricity. Receive the data fed back by the meter, perform a preliminary integrity and accuracy check on the data, and check whether there are problems such as packet loss, checksum errors, etc.

[0015] S1.3. For different types of sensors, send a request to read data according to their protocols, and receive and store the data.

[0016] S1.4. Integrate the data collected from the meter and different sensors into a temporary data buffer. Add a source tag to each data, indicating which meter or specific sensor it comes from, and mark the timestamp of data collection to facilitate data tracing and synchronization during subsequent data processing and analysis.

[0017] Furthermore, the step S2 comprises the following steps:

[0018] S2.1. Check the Type II collector to ensure that its power supply is stable. At the same time, check the RS-485 interface to confirm that the physical connection of the interface is firm and there is no sign of damage. Ensure that the communication line is normal. Start the Type II collector and load the pre-set parameters, including communication baud rate, data bit, stop bit, check bit and other RS-485 communication parameters to match them with the settings of the terminal device and prepare for data transmission.

[0019] S2.2, Type II collector sends a communication request to the terminal device through the RS-485 interface and waits for the terminal device to respond. When the terminal device receives the request and confirms it, a stable communication link is established between the two parties. Type II collector sends a data transcription request to the terminal device, and the request information contains instructions such as the type of data and range to be obtained. After receiving the request, the terminal device sends the collected data to the microcontroller through the RS-485 interface according to the instructions. When the microcontroller receives the data, it reads the data byte by byte and temporarily stores it, and performs simple checks, such as parity checks, to ensure that there are no errors in the data transmission process.

[0020] S2.3. After receiving the complete data, the MCU processes the data. This may include parsing the data format, grouping the received raw data according to certain rules, and identifying the data of different meters and sensors. For some data that may contain errors or abnormalities, mark them or take certain error correction measures. The MCU stores the processed data in its own storage medium. During the storage process, the data is stored separately according to the meter and sensor numbers according to the type and source of the data, which is convenient for subsequent data query and analysis. At the same time, when storing data, the timestamp of the data storage can also be recorded to facilitate tracking the timeliness of the data.

[0021] Furthermore, step S3 includes the following steps:

[0022] S3.1 configures the MCU's IP address, subnet mask, default gateway, DNS server, etc.; ensures that the MCU runs stably and efficiently in the network environment.

[0023] The S3.2 server generates instructions according to the established protocol and encapsulates them in an IP data packet. This data packet contains information such as the source and target IP addresses, and is accurately sent to the microcontroller based on the network communication mechanism, providing an instruction basis for its operation and ensuring the orderly operation of the system.

[0024] S3.3 starts the network receiving module of the Type II collector and prepares to receive IP data packets from the server. When the IP data packet reaches the MCU through network transmission, the MCU uses its built-in network protocol stack to capture the IP data packet. Subsequently, the received IP data packet is deeply analyzed. During the analysis process, the MCU must accurately identify the various components of the IP data packet and extract the key data content from it. Then, through the conversion program, the MCU converts the extracted data according to the data format of the corresponding protocol required for communication with the terminal device. Finally, using the established communication link, the converted data is sent to the terminal device efficiently and accurately to ensure that the terminal device can obtain the correct instructions or data and ensure the stable operation of the entire system.

[0025] Furthermore, the step S4 comprises the following steps:

[0026] S4.1. Collect queue status information (MAC layer, such as the number of data packets, etc.) and channel status information (PHY layer, such as amplitude-frequency response, etc.) of each STA.

[0027] S4.2. Calculate the utility function value according to the user queue and service type to determine the priority, and schedule high-priority users first. Divide STA into real-time STA and non-real-time STA according to different terminal types.

[0028] The utility function of real-time STA is expressed as:

[0029]

[0030] in It is represented as the packet loss of STA at the current moment, expressed as

[0031]

[0032] in is the packet loss rate, Packet Error Rate

[0033]

[0034] represents the maximum acceptable packet loss, τ k represents the data waiting delay of STA with sequence number k, τmax represents the maximum allowed waiting delay, V min (t) represents the minimum rate requirement to avoid the waiting delay exceeding the maximum allowed delay,

[0035]

[0036] M contains the number of scheduling bits for each data packet, and the delay coefficient α is introduced in the formula2 In the user scheduling algorithm, considering the delay coefficient can help the system give priority to delay-sensitive services and ensure that the QoS (quality of service) requirements of these services are met. At time slot t, the queue length in the buffer area of ​​the STA buffer at the previous moment is Q k (t) indicates. k (t) represents the number of packets arriving at the STA in the current OFDM symbol period, and α is introduced k ,β k ,γ k The three data weighting factors are used to adjust the importance of these factors.

[0037] The utility function expression of non-real-time STA is

[0038]

[0039] This formula is used to measure the satisfaction of non-real-time STA with packet loss at the tth OFDM symbol time. 1 and ε 2 are two parameters greater than 0, used to adjust the shape and steepness of the utility function curve.

[0040] S4.3. Initialize system parameters (number of subcarriers, etc.), allocate subcarriers and power resources to scheduled users to meet their minimum required rate. If the user's minimum required rate is met, update the user set and system remaining resources.

[0041] (1) Calculate the maximum rate that each user can transmit on each subcarrier, represented by matrix r. The system subcarrier set is represented by C. For the scheduled users in the set S, find the subcarrier set that can provide the maximum transmission rate for the current STA with sequence number k in the matrix, denoted by Ω. k , this rule is to find the subcarrier set C such that r k,n The set consisting of the largest subcarrier n is obtained, and the determination method is as shown in the formula:

[0042] Ω k ={n / n∈C and n=argmax(r k,n )}

[0043] (2) In the set Ω k Find the subcarrier n that uses the least power + , n + Assigned to the current STA. + It can be expressed as

[0044]

[0045] If the subcarrier set is empty, the allocation ends at this time. For the remaining users in S, steps (1) and (2) are repeated in sequence until the set S is an empty set.

[0046] S4.4. After the multi-STA cross-layer resource allocation is completed, the Type II collector (STA) uploads the pre-collected data to the server through cross-layer resource allocation, and the terminal needs to perform data pre-collection again, store the collected data in the Type II collector (STA), and repeat steps S1 to S4.

[0047] Compared with the prior art, the present invention has the following beneficial effects:

[0048] 1. Real-time data collection: After testing, the Type II collector integrates pre-collection and data caching technology, which greatly guarantees the real-time nature of the data.

[0049] 2. Terminal access in multiple scenarios: Through the IP technology of the substation, terminals with different protocols are uniformly converted into IP data packets, such as the smart meters and various sensors in the experiment, which solves the limitations of traditional power collection and expands the scope of application.

[0050] 3. Multi-STA uplink conflict suppression: By introducing cross-layer resource allocation technology, the uplink conflict problem existing in the multi-STA concurrent mechanism is solved. Compared with the common resource allocation algorithm, the average throughput and delay are greatly optimized. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] The accompanying drawings are used to provide further understanding of the present invention and constitute a part of the specification. They are used to explain the present invention together with the embodiments of the present invention and do not constitute a limitation of the present invention.

[0052] Figure 1 This is a schematic diagram of the multi-scenario application architecture of the power Internet of Things proposed in the present invention.

[0053] Figure 2 This is a flow chart of a multi-scenario data collection method for the power Internet of Things based on HPLC proposed by the present invention.

[0054] Figure 3 This is a flow chart of "terminal device startup, data acquisition and integration" for a multi-scenario data collection method for the power Internet of Things based on HPLC proposed in the present invention.

[0055] Figure 4 This is a flow chart of "Type II collector (STA) data transcription and storage" for a multi-scenario data collection method for the power Internet of Things based on HPLC proposed by the present invention.

[0056] Figure 5This is a flow chart of "server sending data collection instructions and protocol conversion" for a multi-scenario data collection method for the power Internet of Things based on HPLC proposed by the present invention.

[0057] Figure 6 This is a flow chart of "STA uploading data and cross-layer allocation of resources" for a multi-scenario data collection method for the power Internet of Things based on HPLC proposed by the present invention.

[0058] Figure 7 This is a comparison chart of average throughput between the improved multi-STA resource allocation algorithm of the present invention and the traditional resource allocation algorithm.

[0059] Figure 8 This is a comparison chart of average delay between the improved multi-STA resource allocation algorithm of the present invention and the traditional resource allocation algorithm.

[0060] Fig. 9 Schematic diagram related to system testing and verification built for the present invention. DETAILED DESCRIPTION

[0061] In order to make the purpose, technical solution and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the accompanying drawings and embodiments. Of course, the specific embodiments described here are only used to explain the present invention and are not used to limit the present invention.

[0062] Example 1

[0063] See the schematic diagram of the multi-scenario application architecture of the power Internet of Things for details. Figure 1 This embodiment provides a multi-scenario data collection method for power Internet of Things based on HPLC, see Figure 2 , including the following steps:

[0064] S1: The terminal device first performs a data pre-collection, including different protocol data collected by the meter and various sensors; S2: The single-chip microcomputer in the type II collector transcribes and stores the data collected by the terminal device through the RS-485 interface; S3: The server issues a data collection instruction, which is sent to the terminal device after being converted by the single-chip microcomputer protocol;

[0065] S4: The single chip microcomputer uploads the last stored data to the server after IP protocol conversion and cross-layer resource allocation. The terminal device continues to collect data and repeats steps S1 to S4.

[0066] like Figure 3 As shown, step S1 includes the following steps:

[0067] S1.1. The terminal device starts up, loads the relevant driver and configuration files, and ensures that its functional modules are operating normally. Perform a self-test on the hardware interface, including checking whether the communication ports connected to the meter and sensor, such as the RS-485 interface and the communication module, are operating normally and confirming that there is no fault or damage.

[0068] S1.2. Establish a communication link with the meter by identifying the meter's communication protocol, such as the specific meter protocol under the RS-485 communication protocol. Send a data request instruction to the meter. The instruction content is formulated according to the meter protocol, covering acquisition requests for different data types such as voltage, current, power, and electricity. Receive the data fed back by the meter, perform a preliminary integrity and accuracy check on the data, and check whether there are problems such as packet loss, checksum errors, etc.

[0069] S1.3. For different types of sensors, send a request to read data according to their protocols, and receive and store the data.

[0070] S1.4. Integrate the data collected from the meter and different sensors into a temporary data buffer. Add a source tag to each data, indicating which meter or specific sensor it comes from, and mark the timestamp of data collection to facilitate data tracing and synchronization during subsequent data processing and analysis.

[0071] like Figure 4 As shown, step S2 includes the following steps:

[0072] S2.1. Check the Type II collector to ensure that its power supply is stable. At the same time, check the RS-485 interface to confirm that the physical connection of the interface is firm and there is no sign of damage, and ensure that the communication line is normal. Start the Type II collector and load the pre-set parameters. Including communication baud rate, data bit, stop bit, check bit and other RS-485 communication parameters, make them match the settings of the terminal equipment, and prepare for data transmission.

[0073] S2.2, Type II collector sends a communication request to the terminal device through the RS-485 interface and waits for the terminal device to respond. When the terminal device receives the request and confirms it, a stable communication link is established between the two parties. Type II collector sends a data transcription request to the terminal device, and the request information contains instructions such as the type of data and range to be obtained. After receiving the request, the terminal device sends the collected data to the microcontroller through the RS-485 interface according to the instructions. When the microcontroller receives the data, it reads the data byte by byte and temporarily stores it, and performs simple checks, such as parity checks, to ensure that there are no errors in the data transmission process.

[0074] S2.3. After receiving the complete data, the MCU processes the data. The received raw data is grouped according to certain rules to identify the data of different meters and sensors. Some data that may contain errors or abnormalities are marked or certain error correction measures are taken. The MCU stores the processed data in its own storage medium. During the storage process, the data is stored separately according to the type and source of the data and the numbers of the meters and sensors, which is convenient for subsequent data query and analysis. At the same time, when storing data, the timestamp of the data storage can also be recorded to facilitate tracking the timeliness of the data.

[0075] like Figure 5 As shown, step S3 includes the following steps:

[0076] S3.1 configures the MCU's IP address, subnet mask, default gateway, DNS server, etc.; ensures that the MCU runs stably and efficiently in the network environment.

[0077] The S3.2 server generates instructions according to the established protocol and encapsulates them in an IP data packet. This data packet contains information such as the source and target IP addresses, and is accurately sent to the microcontroller based on the network communication mechanism, providing an instruction basis for its operation and ensuring the orderly operation of the system.

[0078] S3.3 starts the network receiving module of the Type II collector and prepares to receive IP data packets from the server. When the IP data packet reaches the MCU through network transmission, the MCU uses its built-in network protocol stack to capture the IP data packet. Subsequently, the received IP data packet is deeply analyzed. During the analysis process, the MCU must accurately identify the various components of the IP data packet and extract the key data content from it. Then, through the conversion program, the MCU converts the extracted data according to the data format of the corresponding protocol required for communication with the terminal device. Finally, using the established communication link, the converted data is sent to the terminal device efficiently and accurately to ensure that the terminal device can obtain the correct instructions or data and ensure the stable operation of the entire system.

[0079] like Figure 6 As shown, step S4 includes the following steps:

[0080] S4.1. Collect queue status information (MAC layer, such as the number of data packets, etc.) and channel status information (PHY layer, such as amplitude-frequency response, etc.) of each STA.

[0081] S4.2. Calculate the utility function value according to the user queue and service type to determine the priority, and schedule high-priority users first. Divide STA into real-time STA and non-real-time STA according to different terminal types.

[0082] The utility function of real-time STA is expressed as:

[0083]

[0084] in It is represented as the packet loss of STA at the current moment, expressed as

[0085]

[0086] in is the packet loss rate, Packet Error Rate

[0087]

[0088] represents the maximum acceptable packet loss, τ k represents the data waiting delay of STA with sequence number k, τmax represents the maximum allowed waiting delay, V min (t) represents the minimum rate requirement to avoid the waiting delay exceeding the maximum allowed delay,

[0089]

[0090] M contains the number of scheduling bits for each data packet, and the delay coefficient α is introduced in the formula 2 In the user scheduling algorithm, considering the delay coefficient can help the system give priority to delay-sensitive services and ensure that the QoS (quality of service) requirements of these services are met. At time slot t, the queue length in the buffer area of ​​the STA buffer at the previous moment is Q k (t) indicates. k (t) represents the number of packets arriving at the STA in the current OFDM symbol period, and α is introduced k ,β k ,γ k The three data weighting factors are used to adjust the importance of these factors.

[0091] The utility function expression of non-real-time STA is

[0092]

[0093] This formula is used to measure the satisfaction of non-real-time STA with packet loss at the tth OFDM symbol time. 1 and ε 2 are two parameters greater than 0, used to adjust the shape and steepness of the utility function curve.

[0094] S4.3. Initialize system parameters (number of subcarriers, etc.), allocate subcarriers and power resources to scheduled users to meet their minimum required rate. If the user's minimum required rate is met, update the user set and system remaining resources.

[0095] (1) Calculate the maximum rate that each user can transmit on each subcarrier, represented by matrix r. The system subcarrier set is represented by C. For the scheduled users in the set S, find the subcarrier set that can provide the maximum transmission rate for the current STA with sequence number k in the matrix, denoted by Ω. k , this rule is to find the subcarrier set C such that r k,n The set consisting of the largest subcarrier n is obtained, and the determination method is as shown in the formula:

[0096] Ω k ={n / n∈C and n=argmax(r k,n )}

[0097] (2) In the set Ωk, find the subcarrier n that uses the least power + , n + Assigned to the current STA. + It can be expressed as

[0098]

[0099] If the subcarrier set is empty, the allocation ends at this time. For the remaining users in S, steps (1) and (2) are repeated in sequence until the set S is an empty set.

[0100] S4.4, multi-STA cross-layer resource allocation is completed, the Type II collector (STA) uploads the pre-collected data to the server through cross-layer resource allocation, and the terminal needs to perform data pre-collection again, store the collected data in the Type II collector (STA), and repeat S1 to S4.

[0101] Example 2

[0102] This example provides a comparison of the average throughput and average delay of the traditional multi-STA (Type II collector) resource allocation algorithm and the improved algorithm of this embodiment.

[0103] like Figure 7As shown, the total average throughput of the algorithm of this embodiment and the comparison algorithm are similar, but in the comparison algorithm, the throughput indicator of STAs with good channel quality is higher than that of STAs with poor channel quality. This is because the maximum throughput algorithm preferentially allocates resources to RTB1 and NRTB1 with better quality, resulting in insufficient resources for RTB2 and NRTB2 with poor channel quality, which cannot meet the QoS requirements of STAs. This fully demonstrates that the algorithm does not consider the fairness between different types of STAs. In contrast, the algorithm of this embodiment fully considers the QoS and fairness requirements of different services when resources are sufficient, so that different types of STAs can meet the QoS rate.

[0104] like Figure 8 As shown, it is clearly observed that the average delay of the maximum throughput algorithm shows a rapid upward trend over time. This phenomenon occurs because the maximum throughput algorithm may have certain limitations in the rationality and timeliness of resource allocation in the process of pursuing high throughput, resulting in a rapid increase in the delay of business processing over time. In sharp contrast, the average delay of the algorithm proposed in this embodiment shows a relatively stable state under the same resource-sufficient environment. This means that during the entire network operation process, the average congestion level of the system corresponding to the algorithm of this embodiment is low. This is due to the optimization of the algorithm of this embodiment in the resource allocation strategy. It can more reasonably allocate resources according to the business type and real-time demand, effectively avoiding unnecessary delays, thereby ensuring the stable operation of the system.

[0105] Example 3

[0106] like Fig. 9 As shown, in order to verify the feasibility and stability of the scheme, an experimental system was built for testing and verification, including 1 type I concentrator, 3 new type II collectors, 3 electricity meters, and 1 temperature, humidity and smoke sensor. This embodiment collects data from 3 electricity meters (connected to 1 collector) and 2 sensors at the same time. The test terminal mainly includes smart meters and sensors, among which the new type II collector collects electricity consumption information of the electricity meter and environmental data collected by the sensor through the RS-485 interface. After testing, since the type II collector integrates data caching technology and protocol conversion technology, the time for one round of collection is only 10.97 seconds. In addition, in order to further test the stability of the system, data collection is carried out every 5 minutes, and a total of 500 times are collected. The test results are shown in Table 1 below. The success rate of various parameter collections reached 100%.

[0107] Table 1

[0108]

[0109] Compared with the traditional solution that can only read a single meter at a time, the new type II collector proposed in this embodiment can mount multiple meters at one time, and can read the real-time data of multiple meters at a time, which greatly improves the real-time performance of data collection. While reading conventional power data, it can also collect various environmental parameters, broaden the application scenarios, and effectively solve the data uplink conflict problem existing in the HPLC communication concurrency mechanism. The test results show that compared with the traditional collection scheme, this embodiment can greatly improve the data collection efficiency and collection types, and has a strong value for promotion and application.

[0110] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims

1. A multi-scenario data collection method for power Internet of Things based on HPLC, which is implemented based on a power Internet of Things system. The power Internet of Things system includes a server, a management device, a collection device, and a terminal device. The collection device includes a single-chip microcomputer with storage and control functions. The terminal device includes an electric meter and various sensor monitoring devices for monitoring and surveillance scenes. It is characterized in that: The data collection method includes the following steps: S1: The terminal device first performs data pre-collection, including different protocol data collected by the electricity meter and various sensors; S2: The microcontroller in the Type II collector transcribes and stores the data collected by the terminal device through the RS-485 interface; S3: The server issues data collection instructions, which are converted by the microcontroller protocol and sent to the terminal device; S4: The single chip microcomputer uploads the last stored data to the server after IP protocol conversion and cross-layer resource allocation, and the terminal device continues to collect data, repeating the above steps S1 to S4.

2. The HPLC-based multi-scenario data acquisition method for electric power Internet of Things according to claim 1 is characterized in that: The step S1 comprises the following steps: S1.

1. The terminal device starts, loads the relevant driver and configuration files, ensures that its functional modules are operating normally, and performs self-tests on the hardware interfaces, including checking the communication ports connected to the meter and sensor, such as the RS-485 interface, and whether the communication module is operating normally and confirming that there is no fault or damage; S1.

2. Establish a communication link with the meter by identifying the specific meter protocol under the RS-485 communication protocol of the meter, send a data request instruction to the meter, the instruction content is formulated according to the meter protocol, covering the acquisition request of different data types such as voltage, current, power and electricity, receive the data fed back by the meter, perform preliminary integrity and accuracy check on the data, and check whether there is packet loss, checksum error or other errors in the data; S1.

3. For different types of sensors, send a request to read data according to their protocols, and receive and store the data; S1.

4. Integrate the data collected from the electricity meter and different sensors into a temporary data buffer, add a source tag to each data, indicate which electricity meter or specific sensor it comes from, and mark the timestamp of data collection to facilitate data tracing and synchronization during subsequent data processing and analysis.

3. The HPLC-based multi-scenario data acquisition method for electric power Internet of Things according to claim 1 is characterized in that: The step S2 comprises the following steps: S2.

1. Check the Type II collector to ensure that its power supply is stable. Check the RS-485 interface to confirm that the physical connection of the interface is firm and there is no sign of damage. Ensure that the communication line is normal. Start the Type II collector and load the pre-set parameters, including communication baud rate, data bit, stop bit, check bit RS-485 communication parameters, to match them with the settings of the terminal device and prepare for data transmission. S2.2, Type II collector sends a communication request to the terminal device through the RS-485 interface and waits for the terminal device to respond. When the terminal device receives the request and confirms it, the two parties establish a stable communication link. Type II collector sends a data transcription request to the terminal device. The request information contains the type of data and range instructions to be obtained. After receiving the request, the terminal device sends the collected data to the microcontroller through the RS-485 interface according to the instructions. When the microcontroller receives the data, it reads the data byte by byte and temporarily stores it. At the same time, a simple check is performed to ensure that there is no error in the data transmission process; S2.

3. After receiving the complete data, the single-chip microcomputer processes the data, including parsing the data format, grouping the received raw data according to certain rules, identifying the data of different meters and sensors, marking some erroneous or abnormal data or taking certain error correction measures. The single-chip microcomputer stores the processed data in its own storage medium. During the storage process, it stores the data separately according to the type and source of the data and the numbers of the meters and sensors, which is convenient for subsequent data query and analysis. When storing data, it also records the timestamp of the data storage.

4. The HPLC-based multi-scenario data acquisition method for electric power Internet of Things according to claim 1 is characterized in that: The step S3 comprises the following steps: S3.1 configures the IP address, subnet mask, default gateway, and DNS server of the MCU; ensures that the MCU runs stably and efficiently in the network environment; The S3.2 server generates instructions according to the established protocol and encapsulates them in an IP data packet. This data packet contains the source and target IP information. Based on the network communication mechanism, it is accurately sent to the MCU to provide the instruction basis for its operation and ensure the orderly operation of the system. S3.3 starts the network receiving module of the Type II collector and prepares to receive the IP data packet from the server. When the IP data packet reaches the MCU through the network transmission, the MCU uses its built-in network protocol stack to capture the IP data packet. Then, it conducts in-depth analysis of the received IP data packet. During the analysis process, the MCU must accurately identify the various components of the IP data packet and extract the key data content from it. Then, through the conversion program, the MCU converts the extracted data according to the data format of the corresponding protocol required for communication with the terminal device. Finally, using the established communication link, the converted data is sent to the terminal device efficiently and accurately to ensure that the terminal device can obtain the correct instructions or data and ensure the stable operation of the entire system.

5. The HPLC-based multi-scenario data acquisition method for electric power Internet of Things according to claim 1 is characterized in that: The step S4 comprises the following steps: S4.

1. Collect queue status information and channel status information of each STA; S4.

2. Calculate the utility function value according to the user queue and service type to determine the priority, give priority to scheduling high-priority users, and divide STAs into real-time STAs and non-real-time STAs according to different terminal types; The utility function of real-time STA is expressed as: in It is represented as the packet loss of STA at the current moment, expressed as in is the packet loss rate, Packet Error Rate represents the maximum acceptable packet loss, τ k represents the data waiting delay of STA with sequence number k, τmax represents the maximum allowed waiting delay, V min (t) represents the minimum rate requirement to avoid the waiting delay exceeding the maximum allowed delay, M contains the number of scheduling bits for each data packet. The delay coefficient α2 is introduced in the formula. In the user scheduling algorithm, considering the delay coefficient can help the system give priority to delay-sensitive services and ensure that the QoS service quality requirements of these services are met. At time slot t, the queue length in the buffer area of ​​the STA buffer at the previous moment is Q k (t) indicates that V k (t) represents the number of packets arriving at the STA in the current OFDM symbol period, and α is introduced k ,β k ,γ k These three data weighting factors adjust the importance of these factors; The utility function expression of non-real-time STA is This formula is used to measure the satisfaction of non-real-time STA with packet loss at the tth OFDM symbol time. ε1 and ε2 are two parameters greater than 0, which are used to adjust the shape and steepness of the utility function curve. S4.

3. Initialize system parameters, allocate subcarriers and power resources to scheduled users to meet their minimum required rate. If the minimum required rate of the user is met, update the user set and the remaining system resources. (1) Calculate the maximum rate that each user can transmit on each subcarrier, represented by matrix r. The system subcarrier set is represented by C. For the scheduled users in the set S, find the subcarrier set that can provide the maximum transmission rate for the current STA with sequence number k in the matrix, denoted by Ω. k , this rule is to find the subcarrier set C such that r k,n The set consisting of the largest subcarrier n is obtained, and the determination method is as shown in the formula: Ω k ={n / n∈C and n=argmax(r k,n )} (2) In the set Ωk, find the subcarrier n that uses the least power + , n + Distribute to current STA, n + Expressed as If the subcarrier set is empty, the allocation ends, and steps (1) and (2) are repeated for the remaining users in S until the set S is empty. S4.

4. After the multi-STA cross-layer resource allocation is completed, the Type II collector uploads the pre-collected data to the server through cross-layer resource allocation, and the terminal needs to perform data pre-collection again, store the collected data in the Type II collector, and repeat steps S1 to S4.

Images