Edge end data acquisition method and system based on HTTP (Hyper Text Transport Protocol) proxy

Abstract

The invention discloses a side end data acquisition method and system based on an HTTP proxy. The method comprises the steps of 1, initializing link and equipment information, 2, receiving and verifying an HTTP request, 3, forwarding a request message, 4, preparing a side end data response, and 5, returning data and generating the response. The system comprises a proxy cloud software module and a daemon side end software module. The invention has the advantages of simple maintenance, safety, reliability, high-efficiency circulation and cost saving.

Description

Technical Field

[0001] The present invention relates to the technical field of data acquisition, and particularly relates to a method and system for edge - end data acquisition based on HTTP proxy. Background Art

[0002] At present, with the rapid development of industrial Internet and Internet of Things, edge - end data acquisition and remote monitoring become increasingly important. In many fields such as energy management and industrial automation, a large number of embedded devices are responsible for collecting various key data, such as the voltage and current of the battery management system (BMS), the working state of the power conversion system (PCS), and the real - time data of the electricity meter. These data are not only used for local energy strategy management but also need to be transmitted through the network for display and analysis on a remote web page to achieve real - time monitoring and precise control of the entire system.

[0003] Currently, there are various technical solutions in the field of data acquisition, but they all have obvious drawbacks. Taking the MQTT technical solution as an example, in actual deployment, the edge - end needs to implement the MQTT Client client. On the public - network server, not only the MQTT server needs to be deployed, but also the MQTT client needs to run. The data is first transmitted from the edge - end to the server via MQTT. The MQTT client subscribes to the corresponding message on the server side and stores the data in the database. Finally, the browser obtains the data from the database through an HTTP request and performs page rendering and display. This solution exposes many problems in complex industrial scenarios. On the one hand, there are many related modules, involving the MQTT services and clients on the edge - end client and server side, as well as the database and other links, which makes the entire data transmission link extremely complex. Once a failure occurs, it is extremely difficult to troubleshoot the problem. On the other hand, the communication characteristics of MQTT itself determine that its transmission speed is slow, resulting in data lagging behind the HTTP request directly read from the database. In addition, the data needs to be stored in the database first and then retrieved from the database and returned to the web back - end program. The repeated disk - in and disk - out of the data seriously affects the data transmission efficiency. More importantly, this solution requires maintaining two communication protocols, HTTP and MQTT, at the same time. Back - end developers also need to deeply understand the table structure of the database for data storage and retrieval operations, which undoubtedly greatly increases the development and maintenance costs.

[0004] Another commonly used intranet penetration technology is represented by the open-source software FRP. Compared with the MQTT solution, it reduces some intermediate links, realizes data transparent transmission, and improves the efficiency of data display to a certain extent. However, in the scenario of large-scale device access, the defects of this solution are also very prominent. First, each device needs to use a port for mapping, and the port resources are extremely limited, with a total of only 65,535. When the number of access devices is large, the port resources will soon be exhausted. Second, since HTTP is based on TCP communication, a large number of port mappings mean frequent TCP link establishment and closure, which will generate huge performance overhead and seriously affect the performance of the public network server. Moreover, a large number of ports are exposed in the public network environment, making the system face severe network security risks and being easily attacked by various unknown crawlers and external networks, seriously threatening the security of edge device management.

[0005] In summary, in terms of edge data collection and display, the existing technologies are difficult to simultaneously meet the requirements of simple link, high data efficiency, security and reliability, and low TCP overhead. There is an urgent need for a new technical solution to solve these problems. Summary of the Invention

[0006] To solve the above problems, especially the deficiencies of the existing technologies, the present invention provides an edge data collection method and system based on HTTP proxy that can solve the above problems.

[0007] To achieve the above object, the present invention adopts the following technical means:

[0008] An edge data collection method based on HTTP proxy is as follows:

[0009] Step 1: Initialize link and device information

[0010] The daemon software of the edge device initiates a Websocket or Coap connection to the proxy software of the cloud server, and carries the sn code of the edge device in the connection request. The proxy software maintains an active channel based on the received sn code and establishes a channel mapping relationship table indexed by the sn code;

[0011] Step 2: Receive and verify HTTP requests

[0012] The HTTP server module of the proxy software receives the HTTP request message, which contains the sn code of the device for which data is to be obtained; the proxy software verifies the validity of the sn code according to the channel mapping relationship table; if the sn code does not exist, it returns device exception information to the HTTP requestor and terminates this communication; if the sn code is valid, proceed to the next step;

[0013] Step 3: Forward the request message

[0014] The proxy software compresses the HTTP request message and sends it to the edge daemon software corresponding to the sn code through the corresponding information channel established in Step 1;

[0015] Step 4: Edge-side data response preparation

[0016] After receiving the compressed request message, the edge daemon software performs decompression and verification operations to confirm that the request points to its own device; according to the message information, it collects the corresponding device data and compresses the data;

[0017] Step 5: Data transmission back and response generation

[0018] The edge daemon software transmits the compressed data back to the proxy software through the information channel; the proxy software decompresses the data, analyzes the data content, and reorganizes it into an HTTP response message according to the HTTP protocol specification, and sends it to the HTTP requestor to end this communication.

[0019] A further solution of the present invention is that the proxy software selects to enable the Websocket server module or the Coap server module according to the configuration file, and the daemon software selects to enable the Websocket client module or the Coap client module according to the configuration file.

[0020] A further solution of the present invention is that during the data transmission process in Step 3, if the proxy software does not receive the response message from the edge daemon software within the set timeout period T, it returns device timeout information to the HTTP requestor to end this communication.

[0021] A further solution of the present invention is that the proxy software regularly checks the communication status of each active channel and closes the channels that have not sent messages for a long time to maintain the effectiveness of the communication link.

[0022] An edge-side data acquisition system based on an HTTP proxy includes a proxy cloud software module and a daemon edge software module;

[0023] Proxy cloud software module:

[0024] Deployed on a public cloud server, with a public network IP, and can perform TCP / IP communication with devices with Internet connection capabilities;

[0025] This module integrates an HTTP server module, a Websocket server module, or a Coap server module;

[0026] It is used to receive and manage edge device information, keep the communication link alive, forward HTTP request messages to the corresponding edge daemon software, and forward the data returned by the edge to the HTTP requester.

[0027] daemon edge software module:

[0028] Deployed on an embedded arm device, it has the ability to connect to the network but has no public IP and can initiate network connections outward.

[0029] This module integrates a data acquisition module, a Websocket client module or a Coap client module.

[0030] It is used to collect the original data of edge devices, register the device information as a client to the proxy software, keep the communication link alive, and respond to the requests of the proxy software and send the collected data to the proxy software.

[0031] A further solution of the present invention is that a long connection is established between the proxy cloud software module and the daemon edge software module through the Websocket or Coap protocol to achieve two-way data transmission.

[0032] A further solution of the present invention is that after the daemon edge software module collects data, the data is temporarily stored in the memory of the edge device in a specific format, and when a request from the proxy cloud software module is received, the data is read from the memory and responded to.

[0033] A further solution of the present invention is that the proxy cloud software module performs compression and decompression operations on the received HTTP request messages and the data returned by the edge to reduce data transmission traffic.

[0034] A further solution of the present invention is that the proxy cloud software module can manage the daemon software modules of multiple edge devices, and different daemon software modules are registered and managed in the proxy cloud software module through their respective sn codes.

[0035] The present invention has the following beneficial effects:

[0036] 1. The present invention is easy to maintain: The system only needs to deploy two sets of software, namely the proxy cloud software module and the daemon edge software module, and the deployment process is simple. And there are few open ports, which makes the communication topology clear and concise, greatly reducing the difficulty of daily maintenance and troubleshooting.

[0037] 2. Secure and reliable: The number of public network open ports is small, which greatly reduces the external attack surface, reduces the risk of being attacked by external malicious networks, and ensures the security of edge device management.

[0038] 3. Efficient transfer: Data is directly transmitted without being stored on the ground. Meanwhile, with the long connection feature of Websocket, the frequent establishment and closure of TCP links are reduced, and the overhead is lowered. The Coap protocol realizes two-way communication based on UDP, further improving the data transfer efficiency, achieving efficient data transfer, and having stronger real-time performance.

[0039] 4. Cost savings: Compress the native HTTP communication data to reduce the data transfer traffic, thereby saving the communication traffic cost. And reduce the use of public network server bandwidth, saving the server lease cost. In addition, only one set of HTTP communication protocols needs to be maintained, reducing the workload of business software development and maintenance. At the same time, the cloud software is easy to expand, supporting more edge devices to access, achieving cost reduction and efficiency improvement. Brief Description of the Drawings

[0040] Figure 1 It is the data processing flow chart of the method of the present invention. Detailed Embodiments

[0041] Next, the technical solutions of the present invention will be described clearly and completely in conjunction with the drawings. Obviously, the described embodiments are part of the embodiments of the present invention, rather than all of the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0042] Embodiment 1

[0043] As Figure 1 shown, a method for edge data acquisition based on an HTTP proxy is as follows:

[0044] Step 1. Initialization of link and device information

[0045] The daemon software of the edge device initiates a Websocket or Coap connection to the proxy software of the cloud server, and carries the sn code of the edge device in the connection request. The proxy software maintains an active channel based on the received sn code and establishes a channel mapping relationship table indexed by the sn code;

[0046] Step 2. Receiving and verifying HTTP requests

[0047] The HTTP server module of the proxy software receives the HTTP request message, which contains the sn code of the device for which data is to be obtained; the proxy software verifies the validity of the sn code according to the channel mapping relationship table; if the sn code does not exist, it returns device exception information to the HTTP requestor and terminates this communication; if the sn code is valid, proceed to the next step;

[0048] Step 3: Request Message Forwarding

[0049] The proxy software compresses the HTTP request message and sends it to the edge daemon software corresponding to the sn code through the corresponding information channel established in Step 1;

[0050] Step 4: Edge-side Data Response Preparation

[0051] After receiving the compressed request message, the edge daemon software performs decompression and verification operations to confirm that the request points to its own device; according to the message information, it collects the corresponding device data and compresses the data;

[0052] Step 5: Data Backhaul and Response Generation

[0053] The edge daemon software sends the compressed data back to the proxy software through the information channel; the proxy software decompresses the data, analyzes the data content, and reorganizes it into an HTTP response message according to the HTTP protocol specification, and sends it to the HTTP requestor to end this communication.

[0054] The proxy software selects to enable the Websocket server module or the Coap server module according to the configuration file, and the daemon software selects to enable the Websocket client module or the Coap client module according to the configuration file.

[0055] The benefits of the above settings are as follows:

[0056] Adapting to diverse network environments: In different application scenarios, the network environments vary significantly. In scenarios with stable network signals and extremely high requirements for real-time performance, such as intelligent building management systems, the proxy software can be configured to enable the Websocket server module and the daemon software to enable the Websocket client module through the configuration file, leveraging the long connection feature of Websocket to achieve real-time and stable data transmission. In scenarios with a wide network coverage but uneven signal quality, such as meteorological monitoring stations in remote areas, the system can be configured to use the Coap protocol, taking advantage of its low overhead based on the UDP protocol to ensure smooth data transmission in weak network environments.

[0057] Optimizing system performance: Selecting the appropriate protocol module according to the performance configuration of the device can effectively improve system performance. For embedded devices with limited computing resources, enabling the Coap client module can reduce resource consumption during data transmission and prevent the device from running slowly due to excessive resource occupation. In scenarios with a large amount of data transmission and high requirements for transmission speed, such as device monitoring in large data centers, using the Websocket protocol can reduce data transmission latency and improve system response speed.

[0058] Reduce operation and maintenance costs: By flexibly selecting protocol modules through configuration files, the high cost of redevelopment or redeployment of the entire system to adapt to different scenarios is avoided. When the network environment or business requirements change, simply modifying the configuration file can quickly switch protocol modules, reducing the difficulty and cost of operation and maintenance. In the production workshop of an enterprise, the Websocket protocol was initially used for device data collection. However, as the workshop scale expanded and network pressure increased, by modifying the configuration file, the Coap protocol was switched, effectively alleviating network congestion without the need for large-scale equipment or software replacement.

[0059] Ensure stable system operation: The system can dynamically adjust the communication protocols and parameters of the proxy software and daemon software according to network conditions and device loads through the configuration file. When the network is congested, some devices are switched to the Coap protocol to reduce network bandwidth occupancy; when the network is stable, the Websocket protocol is used to ensure the reliability of data transmission. This dynamic adjustment mechanism can ensure that the system always operates stably and efficiently in a complex and changing environment.

[0060] During the data transmission process in Step 3, if the proxy software does not receive a response message from the edge daemon software within the set timeout period T, it returns device timeout information to the HTTP requestor and ends this communication.

[0061] The benefits of the above settings are as follows:

[0062] Ensure system response timeliness: When the network is unstable or the edge device fails, if the proxy software does not have a timeout mechanism, the HTTP requestor may wait for a long time, resulting in business stagnation. Setting the timeout period T enables the proxy software to return device timeout information to the HTTP requestor in a timely manner when it does not receive a response within the specified time, avoiding the requestor waiting indefinitely and ensuring that the system can respond quickly in various situations and maintain the smoothness of the business process. In the industrial park energy consumption monitoring scenario, if a certain edge device fails to respond due to hardware failure, the proxy software quickly feeds back after the timeout, and the park management system can promptly detect and take countermeasures, such as arranging personnel for maintenance.

[0063] Optimize the user experience: When the HTTP requestor does not receive a response for a long time, the user will question the reliability of the system. The timeout mechanism can avoid this situation and quickly inform the user of the reason for the request failure, enabling the user to adjust the operation in a timely manner, resend the request or take other measures. In a small photovoltaic energy storage project, when the operation and maintenance personnel initiate a data request through the web page, if the response of the edge device is delayed due to network fluctuations, the proxy software informs the operation and maintenance personnel of device timeout after the timeout. The operation and maintenance personnel can quickly judge possible problems with the network or device instead of waiting blindly.

[0064] Enhance resource management capabilities: Long waiting for edge device responses will occupy server resources, resulting in other requests not being processed in a timely manner. The timeout mechanism enables the proxy software to end the current communication after the timeout, release the occupied resources, and use them to process other requests, improving the server's resource utilization rate. In a distributed energy management system, with a large number of edge devices and frequent concurrent requests, without a timeout mechanism, the server resources may be exhausted by invalid requests, while the timeout mechanism can effectively avoid this problem and ensure the stable operation of the system under high load.

[0065] Facilitate fault troubleshooting and location: The timeout information not only provides feedback to the HTTP requestor but also provides clues for system operators to troubleshoot faults. By analyzing the frequency of timeout occurrences and the corresponding devices, operators can quickly locate the network faults or device anomalies and repair them in a timely manner. If edge devices in a certain area frequently experience timeouts, operators can focus on checking the network connections or device operating status in that area.

[0066] The proxy software regularly checks the communication status of each active channel and closes the channels that have not sent messages for a long time to maintain the effectiveness of the communication link.

[0067] The benefits of the above settings are as follows:

[0068] Network resources: In the Internet of Things scenario, there are a large number of edge devices. If a large number of active channels that have not been used for a long time are allowed to occupy network resources, it will cause waste of network bandwidth and affect the transmission of other important data. For example, in the street lamp management system of a smart city, thousands of street lamps are used as edge devices. If the proxy software does not close the idle channels, the limited network bandwidth will be occupied by a large number of invalid connections, resulting in important data such as street lamp fault information and dimming instructions not being transmitted in a timely manner.

[0069] Server resources: Each active channel occupies server resources such as memory and CPU. Channels that have not sent messages for a long time continuously occupy these resources, resulting in high server load and affecting the normal operation of other services. By closing such channels, the server can release resources and provide sufficient computing resources for other tasks with high real-time requirements, ensuring the efficient operation of the system.

[0070] Avoid link congestion: A large number of invalid active channels may cause network link congestion, leading to problems such as data transmission delay and packet loss. Regularly closing channels that have not sent messages for a long time can effectively prevent link congestion and ensure that data can still be transmitted stably and reliably under high load conditions. Take an industrial automation production line as an example. The stability of data transmission directly affects the continuity of production. If the link is congested, it may cause production stoppage and result in significant economic losses.

[0071] Detect anomalies in a timely manner: If there is no message in an active channel for a long time, it may be due to reasons such as edge device failure or network connection interruption. The process of the proxy software closing such channels is actually a check on the system running status. In this way, potential problems can be discovered in a timely manner, and corresponding measures can be taken for repair to avoid the expansion of faults and improve the overall stability of the system.

[0072] Prevent malicious exploitation: Active channels that have not been used for a long time may become entry points for hacker attacks. Hackers can use these channels to send malicious data, steal sensitive information, posing a serious threat to system security. Closing these channels can reduce the attack surface of the system, lower security risks, and protect the security of the system and data.

[0073] Ensure data security: In some scenarios with extremely high requirements for data security, such as the financial and medical fields, closing idle channels can effectively prevent data leakage and ensure user privacy and data security.

[0074] An edge data acquisition system based on HTTP proxy includes a proxy cloud software module and a daemon edge software module;

[0075] Proxy cloud software module:

[0076] Deployed on a public cloud server, with a public IP, capable of TCP / IP communication with devices having Internet connection capabilities;

[0077] This module integrates an HTTP server module, a Websocket server module, or a Coap server module;

[0078] Used to receive and manage edge device information, keep the communication link alive, forward HTTP request messages to the corresponding edge daemon software, and forward the data returned by the edge to the HTTP requestor;

[0079] Daemon edge software module:

[0080] Deployed on an embedded arm device, with Internet connection capabilities but without a public IP, capable of initiating an outbound network connection;

[0081] This module integrates a data acquisition module, a Websocket client module, or a Coap client module;

[0082] Used to collect raw data of edge devices, register device information with the proxy software as a client, keep the communication link alive, and respond to the requests of the proxy software to send the collected data to the proxy software.

[0083] A long connection is established between the proxy cloud software module and the daemon edge software module through the Websocket or Coap protocol to achieve two-way data transmission.

[0084] The benefits of the above settings are as follows:

[0085] Advantages of long connection: The Websocket and Coap protocols support long connections. After the connection is established, both parties can continuously transmit data for a period of time without frequently establishing and closing TCP connections. This greatly reduces the overhead in the TCP handshake and wave process, improves the efficiency of data transmission, and enables the system to respond more quickly to data requests. For example, in a real-time monitoring system, edge devices need to continuously send device status data to the cloud. The long connection method can ensure timely and efficient data transmission, avoiding delays caused by frequent connection establishment.

[0086] Value of two-way communication: The Websocket and Coap protocols support two-way data transmission. The proxy cloud software module and the daemon edge software module can actively send and receive data at any time. This enables the cloud to send control instructions to edge devices in real time, and edge devices can also promptly feedback the collected data to the cloud. In a smart home system, users can remotely control smart devices at home through the cloud platform, and at the same time, the status information of the devices can be uploaded to the cloud in real time, providing a more convenient user experience.

[0087] Fast data interaction: The long connection ensures the timeliness of data transmission. When new data is collected by edge devices, it can be immediately sent to the cloud through the long connection; after the cloud receives the data, it can quickly process it and feedback corresponding instructions. This fast data interaction ability enables the system to respond promptly to various changes and improves the real-time performance of the system. In an industrial automation production line, edge sensors continuously collect the operating data of devices and quickly transmit the data to the cloud for analysis through a long connection. Once an abnormal situation is detected, the cloud can immediately send adjustment instructions to edge devices to avoid production accidents.

[0088] Real-time status update: For application scenarios that require real-time status updates, such as logistics tracking and energy management, long connections can ensure data real-time. Edge devices can send the latest location, energy consumption, etc. information to the cloud at any time, and the cloud promptly displays this information to users, enabling users to grasp the operating status of the system in real time.

[0089] After the daemon edge software module collects data, it temporarily stores the data in the memory of the edge device in a specific format. When a request from the proxy cloud software module is received, the data is read from the memory and responded to.

[0090] The benefits of the above settings are as follows:

[0091] Quick response to requests: The read and write speed of memory is extremely fast. The daemon edge software module temporarily stores the collected data in memory. When receiving a request from the proxy cloud software module, it can directly read the data from memory quickly and respond. This significantly reduces the data reading time compared to reading data from storage devices such as hard disks, enabling a quick response to cloud requests and meeting the real-time requirements of the system. For example, in an industrial automation production scenario, when the cloud needs to obtain the operating parameters of production equipment in real time, the edge device stores the collected data in memory and can quickly respond to cloud requests, allowing managers to promptly grasp the production status.

[0092] Reduce resource consumption of edge devices: If the edge device has to read data from external storage devices (such as hard disks, flash memories) every time to respond to cloud requests, it will frequently perform disk I / O operations. This not only increases the device's energy consumption but also accelerates the wear of the storage device and reduces the device's service life. By temporarily storing data in memory, only one write operation from external storage to memory is required when collecting data, and a memory read operation when responding to requests, reducing the number of disk I / Os, thereby reducing the resource consumption and hardware wear of the edge device.

[0093] Improve system stability: The process of reading data from memory is relatively simple and has a low probability of error. When reading data from external storage devices, reading failures or data errors may occur due to storage device failures, file system corruption, etc. Temporarily storing data in memory and responding to requests from memory can avoid these potential risks caused by external storage device problems, improving the stability and reliability of system data transmission. In some scenarios with high requirements for data accuracy and system stability, such as smart grids and medical device monitoring, this method can ensure stable data transmission and normal operation of the system.

[0094] The proxy cloud software module performs compression and decompression operations on the received HTTP request message and the data returned by the edge to reduce data transmission traffic.

[0095] The benefits of the above settings are as follows:

[0096] Reduce data transmission volume: In practical applications, especially in scenarios involving a large amount of data collection and transmission, such as the upload of numerous sensor data in industrial Internet of Things or the aggregation of various device information in smart cities, the amount of original data is often large. By compressing the HTTP request message and the data returned by the edge, the number of bytes of data can be significantly reduced, thereby reducing the required communication traffic.

[0097] Suitable for low-bandwidth networks: In some environments with limited network bandwidth, such as Internet of Things devices in remote areas or mobile devices in weak signal areas, reducing data transmission traffic is particularly important. The compressed data can be transmitted more quickly under limited bandwidth, avoiding network congestion and transmission delays caused by excessive data volume, and ensuring the stable operation of the system under low-bandwidth conditions.

[0098] Improve server processing capacity: The bandwidth resources of public network servers are limited. A large amount of data transmission will occupy the server's bandwidth and affect its processing capacity for other requests. By compressing data, the amount of data transmitted between the server and edge devices is reduced, enabling the server to handle more requests under the same bandwidth conditions, improving the server's concurrent processing capacity and overall performance.

[0099] Reduce server rental costs: For enterprises, server rental is usually billed according to the bandwidth usage. Reducing data transmission traffic means reducing the demand for server bandwidth. Enterprises can choose a lower-bandwidth server configuration, thereby reducing server rental costs. This can significantly save operating costs for application scenarios with large-scale deployment of edge devices and frequent data transmission, such as the device monitoring system in a large industrial park.

[0100] Shorten transmission time: The reduction in data transmission volume directly leads to a shortening of the transmission time. Under a certain network environment, a smaller amount of data can be transmitted to the destination faster through the network, reducing the delay during data transmission. For application scenarios with high real-time requirements, such as real-time monitoring systems and financial trading systems, this can ensure the timely and accurate transmission of data, improving the system's response speed and real-time performance.

[0101] Enhance system stability: Reducing data transmission traffic can also reduce the probability of network packet loss and errors. During data transmission, the larger the amount of data, the higher the possibility of packet loss and errors. By compressing data, the complexity of transmission is reduced, the reliability of data transmission is improved, and the stability of the entire system is enhanced.

[0102] The proxy cloud software module can manage the daemon software modules of multiple edge devices. Different daemon software modules are registered and managed in the proxy cloud software module through their respective SN codes.

[0103] The benefits of the above settings are as follows:

[0104] Clear device identification: The daemon software module of each edge device registers in the proxy cloud software module through a unique SN code, just like assigning a unique "ID card" to each device. This enables the proxy cloud software module to accurately identify and locate each device, greatly improving the accuracy of device management. In a large logistics and warehousing scenario, hundreds or thousands of sensors are distributed in various corners. Through the SN code, the proxy cloud software module can quickly find a specific sensor and configure, monitor, and maintain it.

[0105] Convenient batch operations: Based on the SN code management mechanism, the proxy cloud software module can easily implement batch operations on multiple devices.

[0106] Prevent illegal device access: During the registration process, the proxy cloud software module can verify the SN code of the device. Only devices that pass the verification can successfully register and access the system. This effectively prevents the access of illegal devices and reduces the risk of the system being attacked externally. In the financial data collection scenario, the security of data is crucial. Through the SN code verification mechanism, it can be ensured that only authorized edge devices can communicate with the cloud to protect the security of financial data.

[0107] Data access permission control: The proxy cloud software module can assign different data access permissions to devices based on their SN codes.

[0108] Easily handle the increase in devices: As the business develops, the number of edge devices may continue to increase. With the help of the SN code management mechanism, the proxy cloud software module can easily accommodate new devices without large-scale architecture adjustments. In the construction of a smart city, new IoT devices are constantly deployed. The proxy cloud software module registers and manages the newly added devices through the SN code, achieving the smooth expansion of the system.

[0109] Flexible system architecture: The management method based on the SN code makes the system architecture more flexible. Different types and functions of edge devices can be uniformly managed in the proxy cloud software module through the SN code, providing convenience for the function expansion and upgrade of the system.

[0110] Embodiment 2:

[0111] Small-scale photovoltaic energy storage project

[0112] A certain small-scale photovoltaic energy storage project includes 5 embedded ARM devices for collecting real-time data of photovoltaic panels, PCS, and energy storage batteries.

[0113] System Deployment: Deploy the proxy software on the public cloud server and enable the Websocket server module through the configuration file. Deploy the daemon software on 5 edge embedded arm devices and configure to enable the Websocket client module.

[0114] Data Collection and Transmission: After the edge daemon software starts, initiate a Websocket connection to the proxy software respectively and send their respective sn codes. After the proxy software receives the sn codes, establish an active channel and a channel mapping relationship table. When the operation and maintenance personnel initiate an HTTP request through the web page to obtain the data of a certain device, the HTTP server module of the proxy software receives the request and verifies the sn code. If the sn code is valid, compress the request message and send it to the edge daemon software through the corresponding channel. The edge daemon software decompresses the request, collects the device data and compresses it, and then sends it back to the proxy software through the channel. The proxy software decompresses the data, generates an HTTP response message, and returns it to the web page.

[0115] Example 3:

[0116] Industrial Park Energy Consumption Monitoring

[0117] A certain industrial park has deployed 50 edge devices for energy consumption monitoring, and uses this system for data collection and transmission.

[0118] System Deployment: Deploy the proxy software on the public cloud server. Considering the low overhead characteristics of the UDP protocol, enable the Coap server module through the configuration file. Deploy the daemon software on 50 edge devices and configure to enable the Coap client module.

[0119] Data Collection and Transmission: After the edge daemon software starts, initiate a Coap connection to the proxy software and carry the sn code. The proxy software establishes a channel mapping relationship. The park management system obtains device data through an HTTP request. After the proxy software verifies the sn code, compress the request message and send it to the corresponding edge daemon software. The edge daemon software decompresses the request, collects the data and compresses it and sends it back. The proxy software decompresses the data, generates an HTTP response message, and returns it to the park management system. In addition, the proxy software regularly checks the channel status and closes the channels that have not responded for a long time to ensure the effectiveness of the link.

[0120] Example 4:

[0121] Distributed Energy Management System

[0122] A certain distributed energy management system covers 200 edge devices in different regions and needs to collect energy data in real time.

[0123] System deployment: To meet the system's requirements for flexibility and scalability, multiple proxy software instances are deployed on public cloud servers. Some proxy software instances enable the Websocket server module, and some enable the Coap server module. On edge devices, daemon software that enables the Websocket client module or the Coap client module is deployed based on the device's network environment and performance configuration.

[0124] Data collection and transmission: After the edge daemon software is started, it initiates a connection to the corresponding proxy software and registers the SN code. When the energy management platform initiates an HTTP request, the proxy software verifies the SN code, compresses the request message and sends it to the edge daemon software. The edge daemon software collects data, compresses it and sends it back. The proxy software decompresses the data, generates an HTTP response message, and returns it to the energy management platform. At the same time, the system can dynamically adjust the communication protocols and parameters of the proxy software and daemon software through the configuration file according to the network status and equipment load to ensure stable and efficient operation of the system.

[0125] The examples given in the present invention are not intended to limit the implementation methods. For those skilled in the art, other different forms of changes or modifications can be made based on the above description. It is not necessary and impossible to list all the implementation methods here, and the obvious changes or modifications derived therefrom are still within the protection scope of the present invention.

Claims

1. A method for edge-side data collection based on an HTTP proxy, characterized in that The specific method is as follows: Step 1. Initialize link and device information The daemon software of the edge device initiates a Websocket or Coap connection to the proxy software of the cloud server, and carries the sn code of the edge device in the connection request. Based on the received sn code, the proxy software maintains an active channel and establishes a channel mapping relation table indexed by the sn code; Step 2. Receive and verify HTTP requests The HTTP server module of the proxy software receives the HTTP request message, which contains the sn code of the device for which data is to be obtained; The proxy software verifies the validity of the sn code according to the channel mapping relation table; if the sn code does not exist, it returns device exception information to the HTTP request party and terminates this communication; If the sn code is valid, proceed to the next step; Step 3. Forward the request message The proxy software compresses the HTTP request message and sends it to the corresponding edge daemon software corresponding to the sn code through the corresponding information channel established in Step 1; Step 4. Prepare the edge data response After receiving the compressed request message, the edge daemon software performs decompression and verification operations to confirm that the request points to its own device; according to the message information, it collects the corresponding device data and compresses the data; Step 5. Transmit the data back and generate the response The edge daemon software transmits the compressed data back to the proxy software through the information channel; the proxy software decompresses the data, analyzes the data content, and reorganizes it into an HTTP response message according to the HTTP protocol specification, and sends it to the HTTP request party to end this communication.

2. The edge - side data acquisition method based on HTTP proxy according to claim 1, wherein, The proxy software selects to enable the Websocket server module or the Coap server module according to the configuration file, and the daemon software selects to enable the Websocket client module or the Coap client module according to the configuration file.

3. The edge - side data acquisition method based on HTTP proxy according to claim 1, wherein, During the data transmission process in Step 3, if the proxy software does not receive the response message from the edge daemon software within the set timeout period T, it returns device timeout information to the HTTP request party and ends this communication.

4. The edge - side data acquisition method based on HTTP proxy according to claim 1, wherein The proxy software regularly checks the communication status of each active channel and closes the channels that have not sent messages for a long time to maintain the effectiveness of the communication link.

5. An edge-side data acquisition system based on an HTTP proxy, characterized in that It includes a proxy cloud software module and a daemon edge software module; Proxy cloud software module: Deployed on a public cloud server, with a public IP, and can perform TCP / IP communication with devices with networking capabilities; This module integrates an HTTP server module, a Websocket server module or a Coap server module; It is used to receive and manage edge device information, keep the communication link alive, forward the HTTP request message to the corresponding edge daemon software, and forward the data returned by the edge to the HTTP request party; Daemon edge software module: Deployed on an embedded arm device, with networking capabilities but without a public IP, and can initiate a network connection outward; This module integrates a data acquisition module, a Websocket client module or a Coap client module; It is used to collect the original data of edge devices, register device information as a client to the proxy software, keep the communication link alive, and respond to the requests of the proxy software to send the collected data to the proxy software.

6. The edge - side data acquisition system based on HTTP proxy according to claim 5, characterized in that, A long connection is established between the proxy cloud software module and the daemon edge software module through the Websocket or Coap protocol to achieve two-way data transmission.

7. A side-end data acquisition system based on an HTTP proxy according to claim 5, characterized in that After the daemon edge software module collects data, it temporarily stores the data in the memory of the edge device in a specific format, and reads and responds to the data from the memory when receiving the request of the proxy cloud software module.

8. An edge-side data acquisition system based on an HTTP proxy according to claim 5, characterized in that, The proxy cloud software module performs compression and decompression operations on the received HTTP request message and the data returned by the edge to reduce data transmission traffic.

9. The edge - side data acquisition system based on HTTP proxy according to claim 5, characterized in that, The proxy cloud software module can manage the daemon software modules of multiple edge devices, and different daemon software modules are registered and managed in the proxy cloud software module through their respective sn codes.

Images