A basin water environment monitoring system based on NB-IoT and SCADA

Abstract

The application provides a basin water environment monitoring system based on NB-IoT and SCADA, solves the problems of high monitoring cost, small coverage, limited number of device connections and low data utilization in the prior art basin water environment monitoring technology, and mainly comprises the following steps: a data acquisition module acquires terminal data of an NB-IoT module by expanding and adding the NB-IoT module on an original online instrument; a data transmission and processing module receives terminal data of the NB-IoT module, processes the terminal data to obtain target data, and transmits the target data to a process database PDB of a SCADA system in real time; and a data display module presents the target data to users in the SCADA system in a configuration mode through object linking, so that real-time remote monitoring, data analysis and optimization, diversified data presentation and production process linkage functions are realized. The application relates to the field of basin water environment treatment.

Description

Technical Field

[0001] This invention relates to the field of watershed water environment management, and in particular to a watershed water environment monitoring system based on NB-IoT and SCADA. Background Technology

[0002] Water environment management is a crucial component of public health, social development, and ecological sustainability. With the increasing impact of global climate change, urbanization, and industrialization, water resource scarcity and the severity of water environment problems are on the rise, making water environment management increasingly important in today's society. Online instrumentation monitoring technology plays a vital role in water environment management. Online instruments can provide real-time information on various water quality parameters (such as pH, dissolved oxygen, conductivity, turbidity, and harmful substance content), flow rate, and water level. This data forms the basis for water environment management decisions. Real-time monitoring allows for the timely detection of water quality anomalies, sudden changes in water level, and excessive flow rates, enabling prompt intervention and preventing further deterioration. Furthermore, long-term monitoring of various parameters allows for the optimization of water treatment equipment operation strategies, such as adjusting pump start-up and shutdown times and changing water plant output, to achieve energy conservation, emission reduction, and improved efficiency. In addition, accurate and real-time water environment monitoring and effective data storage can predict future water quality changes and water demand, providing a basis for water resource management and water environment planning, and offering strong technical support for the scientific management and sustainable development of the water environment.

[0003] With the rapid updates and iterations of various sensor technologies and computer network communication technologies, online instrument monitoring technology is also developing towards diversification, intelligence, and networking. Many online instruments have self-calibration, self-diagnosis, and self-cleaning functions, greatly reducing the burden of manual maintenance. Through Internet of Things (IoT) technology, online instruments can transmit monitoring data to remote servers in real time, enabling remote monitoring and management. However, these monitoring technologies often suffer from problems such as high equipment costs, limited data quality control, and insufficient environmental adaptability. This is especially true in water environment monitoring, which faces numerous challenges, including a wide monitoring range, numerous devices, significant changes in environmental conditions, and large data volumes. These factors place high demands on the performance, stability, durability, security, ease of use, and data processing capabilities of water environment monitoring systems.

[0004] Currently, online instrument data acquisition in the water environment field mainly employs online monitoring, remote sensing monitoring, and manual sampling. However, these methods generally suffer from limited coverage, high power consumption and cost, poor durability, low acquisition efficiency, and unstable data. Furthermore, they are not ideal for long-term data storage and effective utilization, exhibiting many shortcomings when facing complex water environment monitoring environments. Therefore, the diversity, cost and scope, adaptability, and data processing of watershed water environment monitoring are the difficulties and challenges of this invention. Summary of the Invention

[0005] This invention aims to provide a watershed water environment monitoring system based on NB-IoT and SCADA, mainly comprising three modules: a data acquisition module, a data transmission and processing module, and a data display module. It addresses the problems of high monitoring costs, limited coverage, limited number of connected devices, and inadequate data utilization in existing watershed water environment monitoring technologies. Furthermore, by integrating with a SCADA system, it enables real-time remote monitoring, data analysis and optimization, diversified data presentation, and production process linkage.

[0006] This invention provides a watershed water environment monitoring system based on NB-IoT and SCADA, which includes a data acquisition module, a data transmission and processing module, and a data display module;

[0007] The data acquisition module is used to expand and add NB-IoT modules to existing online meters for terminal data acquisition.

[0008] The data transmission processing module is used to receive terminal data from the NB-IoT module, process it to obtain target data, and store the target data in a relational database. There are n substations that directly associate the target data table with the client ODBC through the open database connection of the industrial gateway OPC server, and transmit the target data to the process database PDB of the SCADA system in real time.

[0009] The data display module is used to present target data to users in the SCADA system through object links and configuration.

[0010] Preferably, the data acquisition module further includes a selection unit, a hardware access unit, a software integration unit, and a testing and verification unit;

[0011] The module selection unit is used to select a module, which is an NB-IoT module. When selecting an NB-IoT module, the main parameters to be selected are data transmission rate, power consumption, radio frequency performance, size, and temperature range.

[0012] A hardware access unit is used to connect the NB-IoT module to the online instrument through a designed interface circuit, wherein the interface circuit converts the data signal of the online instrument into a digital signal received by the NB-IoT module.

[0013] The software integration unit is used to establish a communication connection after adding an NB-IoT module to the online instrument, and to process the received analog signals. The data processing adopts the following steps:

[0014] Step 1: Initialize the module:

[0015] Use UART (Universal Asynchronous Receiver-Transmitter) or SPI (Serial Peripheral Interface) serial communication interface to physically connect the NB-IoT module to the main control system. After connection, set the baud rate, data bits, and stop bit parameters, start the network connection of the NB-IoT module, and establish a communication connection with the NB-IoT base station.

[0016] Step 2: Set parameters:

[0017] Configure the NB-IoT module's Access Point Name (APN) to enable the NB-IoT module to connect to the NB-IoT network and access the cloud server; select TCP as the transmission protocol and the corresponding port number for sending data packets to the server; then configure the data transmission frequency.

[0018] Step 3: Signal processing module

[0019] 101 Reads the monitoring data from the instrument's sensors, including temperature, humidity, and pressure information;

[0020] The 102 monitoring data is an analog signal, which undergoes analog-to-digital (A / D) conversion.

[0021] 103 calibrates, filters, and compresses the collected monitoring data as raw data, and encapsulates the instrument's monitoring data into binary data packets that are transmitted through the NB-IoT network. It also processes the received data packets.

[0022] The testing and verification unit performs tests and verifications after completing hardware access and software integration, simulating real-world conditions to check whether the system can send and receive data normally. If problems are found, it returns to steps 1 and 2 for modification and adjustment. After integrating the NB-IoT module with the online instrument, the data is sent to the nearest base station through the NB-IoT communication network. The NB-IoT communication mode typically adopts the DRX mode.

[0023] Preferably, the data transmission processing module includes a hardware device layer, a data acquisition layer, and a SCADA monitoring layer;

[0024] The hardware layer involves physical measurements of the monitored target using various sensors to obtain physical measurement data. This physical data is then converted into measurable signal data. An analog-to-digital converter (ADC) converts the continuous analog target signal into a digital target signal, which is then sent to a microprocessor for processing. This processing follows these steps:

[0025] 201 signal filtering

[0026] The acquired raw signals are processed to remove noise and interference to obtain the target data; the filtering method is determined according to the data type and application scenario, and the filtering method includes low-pass filtering, median filtering and high-pass filtering, wherein low-pass filtering is selected for online gas instruments;

[0027] 202 Error Correction

[0028] Error correction is performed on the target data using dynamic correction; the dynamic correction is to correct the collected data based on the real-time operating status or feedback data; through dynamic correction, the target data of the sensor output is adjusted in real time according to the actual situation;

[0029] 203 Data Compression

[0030] The target data is compressed, and the data compression includes lossy compression and lossless compression. Lossless compression is used for instrument data.

[0031] 204 Data Conversion

[0032] After data decompression, the original collected data is converted and encapsulated into the NB-IoT protocol data format for transmission;

[0033] The data acquisition layer receives, processes, and parses the data transmitted from the device, and simultaneously reports the processed device data. The data acquisition layer introduces Redis Stream for congestion control processing.

[0034] The SCADA monitoring layer is used to receive raw data collected from the field equipment layer and transmit it to the SCADA system. The SCADA monitoring layer mainly uses the ODBC Client (Open Database Connectivity) to transmit data from the MySQL database through the OPC Server (OLE for Process Control Server) to the SCADA PDB (Process Database), and finally presents it on the configuration interface in the form of various data links.

[0035] Preferably, the data display module also includes the following:

[0036] a. Establish a monitoring data-integrated distributed SCADA architecture: The construction of the distributed SCADA architecture involves integrating the data collected by n sub-control centers within their respective site ranges into the central station. The central station is configured with enhanced redundancy for disaster recovery and prevention, and the data is ultimately displayed on iClient (Intelligent Client).

[0037] b. Real-time data display: The SCADA system displays data collected from various online instruments in real time, using OCX controls and OLE objects, and employing data linking methods to embed and display the data.

[0038] c. Historical Data Storage and Playback: The historical data stored in the SCADA system is collected, stored, and compressed using a Historian historical database. Collection refers to the real-time and historical monitoring data required for SCADA historical curves and the periodically collected monitoring values ​​required for user reports. Historical monitoring values ​​are compared with a threshold value for periodically collected monitoring values. When the threshold value for periodically collected monitoring values ​​exceeds a preset threshold, the target monitoring value is obtained, compressed, and stored. The threshold value is the difference between the monitoring value in the current period and the monitoring value in the previous period. Specifically, the Swing Door Trending Algorithm is used as follows:

[0039] The threshold is a compression factor C. For data point X, its slope is calculated as follows:

[0040] kx = (Yx - Yb) / (Xx - Xb)

[0041] If |kx - k|>C, store point X and use X as the new starting point; otherwise, ignore point X.

[0042] Where kx represents the slope between data points; in the rotating door compression algorithm, the slope is used to determine whether a data point should be kept or discarded.

[0043] Yx represents the Y-axis value of the target data point, which is usually the data value to be stored.

[0044] Yb represents the Y-axis value of the previous retained data point, which serves as the Y-axis reference point and is the previous retained data point of the target data point;

[0045] Xx represents the X-axis value of the target data point, which is usually a timestamp or the serial number of the data point.

[0046] Xb represents the X-axis value of the previous retained data point, serving as the X-axis reference point. It is the timestamp or sequence number of the previous retained data point of the target data point.

[0047] Preferably, creating an OCX control includes the following steps:

[0048] (1) Create an OCX control: Create a custom OCX control that collects target data from the process database and displays it on the interface;

[0049] (2) Integrating OCX controls: Integrating custom OCX controls into the SCADA system, embedding custom OCX controls into the graphical interface of the SCADA system through ActiveX technology;

[0050] (3) Data association: Associate the OCX control with the data source of the online instrument: After dragging the target data of the OCX control to the configuration screen, set the target data attributes, select the point label stored in the SCADA process database, and associate the label with the same fixed suffix of the real-time target data;

[0051] (4) Real-time update: The SCADA system regularly obtains the latest target data from online instruments and updates it in real time through the OCX control; the target data displayed on the interface is refreshed periodically.

[0052] Preferably, the steps for creating an OLE object are as follows:

[0053] (1) Create an OLE object: Use an application that supports OLE technology (such as Microsoft Office software) to create an OLE object, or obtain an OLE object provided by a third party;

[0054] (2) Embedding OLE objects: In the graphical user interface of the SCADA system, the created OLE objects are embedded into documents or reports; users can access and control the embedded OLE objects by operating on the documents or reports.

[0055] (3) Data association: The SCADA system associates OLE objects with data collected by online instruments through data linking technology, enabling OLE objects to display relevant data. Then, the charts are embedded in the reports, and the real-time target data of the online instruments are dynamically displayed. The specific steps for embedding the reports are as follows:

[0056] a. Create a report: In the report editor of the SCADA system, create a new report file;

[0057] b. Insert OLE object: Insert an OLE object into the report. The OLE object is the real-time target data of the data collected by the online instrument.

[0058] c. Configure data link: Set the data source property of the OLE object, select the data label corresponding to the data value collected by the online instrument in the SCADA process database, associate the OLE object in the report with the source of the real-time data value, set the source property value of the OLE object to the point label in the process database, and when the configuration screen is running, poll and update the data value collected by the online instrument so that the OLE object in the report will dynamically display the real-time target data value associated with the online instrument;

[0059] d. Real-time display: Establish a data link, and the OLE object in the report will refresh the target data on the screen in real time based on the monitoring target data in the SCADA process database. By recording real-time values, the historical trend of the target data can be displayed.

[0060] Preferably, the data linking method includes the following steps:

[0061] (1) Data source configuration: Configure the data source for communication with online instruments, set the data source and communication protocol; the data source is a sensor, a PLC programmable logic controller or other real-time data acquisition device;

[0062] (2) Data association: Real-time data in the data source is associated with OCX controls or OLE objects in the graphical interface through data linking technology; so that the OCX control can display the target data collected by the online instrument in real time;

[0063] (3) Real-time update: The SCADA system periodically updates the associated target data from the data source and displays it in real time through OCX controls or OLE objects.

[0064] Preferably, the test and verification unit typically adopts DRX mode in NB-IoT communication mode. Specifically, in DRX mode, the device does not continuously receive signals, but turns on its receiver during a predetermined DRX period to check if there is incoming data. If there is data, the device will maintain the receiving state; otherwise, the device will turn off its receiver and enter a low-power state.

[0065] The main components of DRX mode are two On-Duration activation durations and DRX inactivity timers.

[0066] On-Duration: This is the period during which the device turns on the receiver and receives downlink transmissions; during this period, the device consumes more energy.

[0067] DRX Inactivity Timer: This timer starts counting down after the device receives data during the on-duration period. When the timer reaches the predetermined time, the device will turn off the receiver and enter a low-power state.

[0068] By adjusting these two parameters, the device's power consumption and latency can be set; if lower power consumption is needed, the DRX cycle can be increased; if lower data transmission latency is needed, the DRX cycle can be decreased; Total energy consumption: E_total = E_active + E_sleep;

[0069] The energy consumption E_active during the active period is proportional to the time T_active during which the device opens the receiver to communicate.

[0070] E_active = k_active * T_active

[0071] Where k_active is a constant representing the energy consumption of the device per unit time, and T_active is the time the device is in an active state, i.e., the active duration.

[0072] The energy consumption during sleep mode, E_sleep, is proportional to the time (T_sleep) it takes for the device to turn off the receiver and enter a low-power state.

[0073] E_sleep = k_sleep * T_sleep

[0074] Where k_sleep is a constant representing the energy consumption of the device per unit time, and T_sleep is the time the device is in sleep mode, which is the DRX cycle minus the on-duration.

[0075] Preferably, the data acquisition layer introduces a Redis message (Redis Stream) stream for congestion control processing, specifically including the following steps:

[0076] a. Creating a Stream: The data from each NB-IoT module is sent as a separate message to a unified message queue. The XADD command is used to add the data from the NB-IoT module to the Stream data stream. The key, message ID, and message content are provided. The message content is key-value data, and the ID is most often represented by *, indicating that the message ID is automatically generated by the Redis in-memory database.

[0077] b. Processing Stream Data: The data acquisition layer uses the built-in XREAD or XREADGROUP commands of the in-memory database Redis to read data from the Stream; XREADGROUP is used to handle data reading in a distributed environment; through the XREADGROUP command and consumer groups, Redis implements a message queue system, where m consumers can concurrently retrieve messages from the Redis message stream to form a consumer group. The consumer group is created by the data acquisition layer using the Redis XGROUP CREATE command. Each consumer group is named with a unique name according to the monitoring type and associated with a specific Stream through a message ID; the XGROUP CREATE command allows specifying the last read message ID of the consumer group, and newly joined consumers can start consuming from the specified position;

[0078] When a consumer reads messages from a Stream message stream using the XREADGROUP command, Redis searches for unacknowledged messages in the group and assigns them to the consumer. Different consumers use different consumer IDs to identify themselves, and each message has a globally unique ID. Redis uses the consumer ID and message ID to identify acknowledged messages. The consumer ID is automatically generated by Redis using a timestamp and sequence number. The message format is: XACK key group ID [ID ……]. The XACK command returns successfully acknowledged message data. The number of successfully acknowledged messages returned by XACK refers to the number of messages on the consumer side being consistent with the total number of messages.

[0079] d. Limit Stream Size: The size of the Stream is limited by the MAXLEN parameter (maximum message length) to prevent it from growing indefinitely. The message format is: XTRIM key MAXLEN [~] count

[0080] The data queue was adjusted and optimized using Little's Law:

[0081] L = λW

[0082] Where L represents the average queue length of the number of unprocessed messages in the Redis Stream;

[0083] λ represents the average number of queue messages arriving at the producer per second in the Redis Stream;

[0084] W represents the average dwell time of a message in a Redis Stream; W is also proportional to the processing rate R of a single message: W = RT;

[0085] T represents the number of unprocessed messages preceding the current message, which needs to be improved by increasing processing speed or increasing the number of consumers;

[0086] The optimization and adjustment plan is as follows:

[0087] (1) Increase processing capacity: If the message generation rate λ is greater than the preset threshold, increase the number of consumers or optimize the processing efficiency R of consumers;

[0088] (2) Reduce waiting time: If there is a difference between the message generation rate λ and the processing rate R, the difference is large when the message generation rate and the processing rate are greater than or equal to the threshold, and dynamic adjustment is required;

[0089] Protocol parsing at the data acquisition layer refers to the protocol parsing of messages after data passes through the Stream queue. This involves splitting, verifying, and structuring data packets according to a predefined private protocol to obtain the final monitoring values.

[0090] The splitting process involves dividing the received data into string arrays using commas as predefined identifiers according to the protocol. The first character represents the message ID, and the second character represents the message type. The validity of data packets within the predefined unique ID and message type is determined using the first two characters. The data is then divided into arrays according to the protocol offsets and parsed sequentially. The parsing method is as follows:

[0091] During parsing, the received data is placed in an array `arr`. Each packet has a sequence number `SensorNum`, 5 data bits, and 3 checksum bits. The array `arr` is then traversed, and the offset `offset` is calculated for each packet.

[0092] offset = 3 + ( sensorNum - 1 ) * 5

[0093] The subtraction of one is due to the fact that the array index starts from 0. The array is traversed based on the calculated offset to obtain all data packets.

[0094] Verification involves outputting the parsed data to the console via log, while simultaneously monitoring the data on the instrument panel in real time to compare their consistency. The actual data V equals the collected data V'. Consistency indicates correct protocol parsing; inconsistency involves printing the data values ​​at each parsing step to determine if there are logical errors. If the code implementation is correct, Wirshark is used to capture packets and verify the original data packets. The correctness of the original data packets is determined by checking whether the target data on the actual instrument display matches the data collected and printed via log.

[0095] Structured storage involves storing the target data, after it has been split and verified, in a structured manner. A monitoring data structure is created, and the detected values ​​are mapped to data categories and key field attributes. The data is then stored in a MySQL relational database. The verified data consists of the actual analog values ​​of different monitoring items collected by the instrument and the detection item types.

[0096] Preferably, the SCADA monitoring layer further includes the following steps:

[0097] a. MySQL Database Storage: The data acquisition layer stores the received NB-IoT data in a MySQL database; after the data is received and parsed by the backend service, the collected data is directly stored into the MySQL database via JDBC (Java Database Connectivity);

[0098] b. Data transmission between the Open Database Connectivity (ODBC) client and the OPC server: Data is obtained from the relational database MySQL through the Open Database Connectivity (ODBC) client of the Industrial Gateway OPC Server (IGS). Data is then transmitted to the SCADA system's process database (PDB) via the standardized Open Database Connectivity (ODBC) client and the process control object linking server (OLE) through the process control object linking server (OPC Server).

[0099] c. Data processing and display of the SCADA system: In the process database PDB of the SCADA system, AI analog point points are created. The AI ​​analog point point is a point point type that is input by AI analog signal and is used to receive continuously changing analog signals. The point point is a unique address or name used to identify and represent a data value. Each analog or digital quantity has a unique point point so that the system can accurately identify and access the data.

[0100] Simultaneously, set parameters such as the refresh frequency and upper and lower limits of the monitoring points. After setting, in the SCADA screen, use the OCX control and OLE object to set its data source attribute value to the monitoring point identifier, obtain the target monitoring data from the PDB process database, and display the target monitoring data in real time on the iFIX configuration interface of the configuration software through data link technology.

[0101] This invention provides a watershed water environment monitoring system based on NB-IoT and SCADA, solving the problems of high monitoring cost, small coverage, limited number of connected devices, and low data utilization in existing watershed water environment monitoring technologies. The system mainly consists of a data acquisition module that adds NB-IoT modules to existing online instruments for terminal data acquisition; a data transmission and processing module that receives and processes the terminal data from the NB-IoT modules to obtain target data, and transmits the target data to the SCADA system's process database (PDB) in real time; and a data display module that presents the target data to the user in the SCADA system through object links and configuration, realizing real-time remote monitoring, data analysis and optimization, diversified data presentation, and production process linkage functions. Attached Figure Description

[0102] Figure 1 This is a schematic diagram of a watershed water environment monitoring system based on NB-IoT and SCADA.

[0103] Figure 2 This is a schematic diagram of the NB-IoT module expansion process for a watershed water environment monitoring system based on NB-IoT and SCADA.

[0104] Figure 3 This is a schematic diagram of the DRX mode operation of a watershed water environment monitoring system based on NB-IoT and SCADA;

[0105] Figure 4 This is a schematic diagram of the overall technical architecture of a watershed water environment monitoring system based on NB-IoT and SCADA.

[0106] Figure 5 This is a diagram illustrating the hardware layer data acquisition process of a watershed water environment monitoring system based on NB-IoT and SCADA.

[0107] Figure 6 This is a diagram illustrating the data reception process of a combustible gas instrument in a watershed water environment monitoring system based on NB-IoT and SCADA.

[0108] Figure 7 This is a schematic diagram illustrating the working principle of an MQTT (Watershed Water Environment Monitoring) system based on NB-IoT and SCADA.

[0109] Figure 8 This is a Redis Stream processing flowchart for a watershed water environment monitoring system based on NB-IoT and SCADA.

[0110] Figure 9This is a distributed application architecture diagram of a watershed water environment monitoring system based on NB-IoT and SCADA.

[0111] Figure 10 This is a configuration data source diagram for a watershed water environment monitoring system based on NB-IoT and SCADA;

[0112] Figure 11 This is a screenshot of real-time data from the OPC Server of a watershed water environment monitoring system based on NB-IoT and SCADA.

[0113] Figure 12 This is a historical data storage configuration diagram for a watershed water environment monitoring system based on NB-IoT and SCADA.

[0114] Figure 13 This is a graph of instrument monitoring data after analysis from a watershed water environment monitoring system based on NB-IoT and SCADA. Detailed Implementation

[0115] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Rather, they are merely examples of apparatuses and methods consistent with some aspects of the invention as detailed in the appended claims.

[0116] This invention provides a watershed water environment monitoring system based on NB-IoT (Narrow Band Internet of Things) and SCADA (Supervisory Control and Data Acquisition) systems, namely a data acquisition and monitoring control system. Figure 1 As shown, the method includes the following steps:

[0117] This invention provides a watershed water environment monitoring system based on NB-IoT and SCADA, which includes a data acquisition module, a data transmission and processing module, and a data display module;

[0118] The data acquisition module is used to expand and add NB-IoT modules to existing online meters for terminal data acquisition.

[0119] The data transmission processing module is used to receive terminal data from the NB-IoT module, process it to obtain target data, and store the target data in a relational database. There are n substations that directly associate the target data table with the client ODBC through the open database connection of the industrial gateway OPC server, and transmit the target data to the process database PDB of the SCADA system in real time.

[0120] The data display module is used to present target data to users in the SCADA system through object links and configuration.

[0121] In one embodiment, the data acquisition module further includes a selection unit, a hardware access unit, a software integration unit, and a testing and verification unit;

[0122] The module selection unit is used to select a module, which is an NB-IoT module. When selecting an NB-IoT module, the main parameters to be selected are data transmission rate, power consumption, radio frequency performance, size, and temperature range.

[0123] A hardware access unit is used to connect the NB-IoT module to the online instrument through a designed interface circuit, wherein the interface circuit converts the data signal of the online instrument into a digital signal received by the NB-IoT module.

[0124] The software integration unit is used to establish a communication connection after adding an NB-IoT module to the online instrument, and to process the received analog signals. The data processing adopts the following steps:

[0125] Step 1: Initialize the module:

[0126] Use UART (Universal Asynchronous Receiver-Transmitter) or SPI (Serial Peripheral Interface) serial communication interface to physically connect the NB-IoT module to the main control system. After connection, set the baud rate, data bits, and stop bit parameters, start the network connection of the NB-IoT module, and establish a communication connection with the NB-IoT base station.

[0127] Step 2: Set parameters:

[0128] Configure the NB-IoT module's Access Point Name (APN) to enable the NB-IoT module to connect to the NB-IoT network and access the cloud server; select TCP as the transmission protocol and the corresponding port number for sending data packets to the server; then configure the data transmission frequency.

[0129] Step 3: Signal processing module

[0130] 101 Reads the monitoring data from the instrument's sensors, including temperature, humidity, and pressure information;

[0131] The 102 monitoring data is an analog signal, which undergoes analog-to-digital (A / D) conversion.

[0132] 103 calibrates, filters, and compresses the collected monitoring data as raw data, and encapsulates the instrument's monitoring data into binary data packets that are transmitted through the NB-IoT network. It also processes the received data packets.

[0133] The testing and verification unit performs tests and verifications after completing hardware access and software integration, simulating real-world conditions to check whether the system can send and receive data normally. If problems are found, it returns to steps 1 and 2 for modification and adjustment. After integrating the NB-IoT module with the online instrument, the data is sent to the nearest base station through the NB-IoT communication network. The NB-IoT communication mode typically adopts the DRX mode.

[0134] In one embodiment, the data transmission processing module includes a hardware device layer, a data acquisition layer, and a SCADA monitoring layer;

[0135] The hardware layer involves physical measurements of the monitored target using various sensors to obtain physical measurement data. This physical data is then converted into measurable signal data. An analog-to-digital converter (ADC) converts the continuous analog target signal into a digital target signal, which is then sent to a microprocessor for processing. This processing follows these steps:

[0136] 201 signal filtering

[0137] The acquired raw signals are processed to remove noise and interference to obtain the target data; the filtering method is determined according to the data type and application scenario, and the filtering method includes low-pass filtering, median filtering and high-pass filtering, wherein low-pass filtering is selected for online gas instruments;

[0138] 202 Error Correction

[0139] Error correction is performed on the target data using dynamic correction; the dynamic correction is to correct the collected data based on the real-time operating status or feedback data; through dynamic correction, the target data of the sensor output is adjusted in real time according to the actual situation;

[0140] 203 Data Compression

[0141] The target data is compressed, and the data compression includes lossy compression and lossless compression. Lossless compression is used for instrument data.

[0142] 204 Data Conversion

[0143] After data decompression, the original collected data is converted and encapsulated into the NB-IoT protocol data format for transmission;

[0144] The data acquisition layer receives, processes, and parses the data transmitted from the device, and simultaneously reports the processed device data. The data acquisition layer introduces Redis Stream for congestion control processing.

[0145] The SCADA monitoring layer is used to receive raw data collected from the field equipment layer and transmit it to the SCADA system. The SCADA monitoring layer mainly uses the ODBC Client (Open Database Connectivity) to transmit data from the MySQL database through the OPC Server (OLE for Process Control Server) to the SCADA PDB (Process Database), and finally presents it on the configuration interface in the form of various data links.

[0146] In one embodiment, the data display module further includes the following:

[0147] a. Establish a monitoring data combined with a distributed SCADA architecture: The construction of the distributed SCADA architecture involves integrating the data collected by n sub-control centers within their respective site ranges into the central station. The central station is configured with enhanced redundancy for disaster recovery and prevention, and the data is ultimately displayed on iClient (Intelligent Client).

[0148] b. Real-time data display: The SCADA system displays data collected from various online instruments in real time, using OCX controls and OLE objects, and employing data linking methods to embed and display the data.

[0149] c. Historical Data Storage and Playback: The historical data stored in the SCADA system is collected, stored, and compressed using a Historian historical database. Collection refers to the real-time and historical monitoring data required for SCADA historical curves and the periodically collected monitoring values ​​required for user reports. Historical monitoring values ​​are compared with a threshold value for periodically collected monitoring values. When the threshold value for periodically collected monitoring values ​​exceeds a preset threshold, the target monitoring value is obtained, compressed, and stored. The threshold value is the difference between the monitoring value in the current period and the monitoring value in the previous period. Specifically, the Swing Door Trending Algorithm is used as follows:

[0150] The threshold is a compression factor C. For a data point X, calculate its slope:

[0151] kx = (Yx - Yb) / (Xx - Xb)

[0152] If |kx - k|>C, store point X and use X as the new starting point; otherwise, ignore point X.

[0153] Where kx represents the slope between data points; in the rotating door compression algorithm, the slope is used to determine whether a data point should be kept or discarded.

[0154] Yx represents the Y-axis value of the target data point, which is usually the data value to be stored.

[0155] Yb represents the Y-axis value of the previous retained data point, which serves as the Y-axis reference point and is the previous retained data point of the target data point;

[0156] Xx represents the X-axis value of the target data point, which is usually a timestamp or the serial number of the data point.

[0157] Xb represents the X-axis value of the previous retained data point, serving as the X-axis reference point. It is the timestamp or sequence number of the previous retained data point of the target data point.

[0158] Preferably, creating an OCX control includes the following steps:

[0159] (1) Create an OCX control: Create a custom OCX control that collects target data from the process database and displays it on the interface;

[0160] (2) Integrating OCX controls: Integrating custom OCX controls into the SCADA system, embedding custom OCX controls into the graphical interface of the SCADA system through ActiveX technology;

[0161] (3) Data association: Associate the OCX control with the data source of the online instrument: After dragging the target data of the OCX control to the configuration screen, set the target data attributes, select the point label stored in the SCADA process database, and associate the label with the same fixed suffix of the real-time target data;

[0162] (4) Real-time update: The SCADA system regularly obtains the latest target data from online instruments and updates it in real time through the OCX control; the target data displayed on the interface is refreshed periodically.

[0163] In one embodiment, the steps for creating an OLE object are as follows:

[0164] (1) Create an OLE object: Use an application that supports OLE technology (such as Microsoft Office software) to create an OLE object, or obtain an OLE object provided by a third party;

[0165] (2) Embedding OLE objects: In the graphical user interface of the SCADA system, the created OLE objects are embedded into documents or reports; users can access and control the embedded OLE objects by operating on the documents or reports.

[0166] (3) Data association: The SCADA system associates OLE objects with data collected by online instruments through data linking technology, enabling OLE objects to display relevant data. Then, the charts are embedded in the reports, and the real-time target data of the online instruments are dynamically displayed. The specific steps for embedding the reports are as follows:

[0167] a. Create a report: In the report editor of the SCADA system, create a new report file;

[0168] b. Insert OLE object: Insert an OLE object into the report. The OLE object is the real-time target data of the data collected by the online instrument.

[0169] c. Configure data link: Set the data source property of the OLE object, select the data label corresponding to the data value collected by the online instrument in the SCADA process database, associate the OLE object in the report with the source of the real-time data value, set the source property value of the OLE object to the point label in the process database, and when the configuration screen is running, poll and update the data value collected by the online instrument so that the OLE object in the report will dynamically display the real-time target data value associated with the online instrument;

[0170] d. Real-time display: Establish a data link, and the OLE object in the report will refresh the target data on the screen in real time based on the monitoring target data in the SCADA process database. By recording real-time values, the historical trend of the target data can be displayed.

[0171] In one embodiment, the data linking method includes the following steps:

[0172] (1) Data source configuration: Configure the data source for communication with online instruments, set the data source and communication protocol; the data source is a sensor, a PLC programmable logic controller or other real-time data acquisition device;

[0173] (2) Data association: Real-time data in the data source is associated with OCX controls or OLE objects in the graphical interface through data linking technology; so that the OCX control can display the target data collected by the online instrument in real time;

[0174] (3) Real-time update: The SCADA system periodically updates the associated target data from the data source and displays it in real time through OCX controls or OLE objects.

[0175] 8. A watershed water environment monitoring system based on NB-IoT and SCADA according to claim 2, characterized in that the test verification unit typically adopts DRX mode in NB-IoT communication mode, specifically meaning that in DRX mode, the device does not continuously receive signals, but turns on its receiver during a predetermined DRX period to check if there is incoming data; if there is data, the device will maintain the receiving state; otherwise, the device will turn off its receiver and enter a low-power state.

[0176] The main components of DRX mode are two On-Duration activation durations and DRX inactivity timers.

[0177] On-Duration: This is the period during which the device turns on the receiver and receives downlink transmissions; during this period, the device consumes more energy.

[0178] DRX Inactivity Timer: This timer starts counting down after the device receives data during the on-duration period. When the timer reaches the predetermined time, the device will turn off the receiver and enter a low-power state.

[0179] By adjusting these two parameters, the device's power consumption and latency can be set; if lower power consumption is needed, the DRX cycle can be increased; if lower data transmission latency is needed, the DRX cycle can be decreased; Total energy consumption: E_total = E_active + E_sleep;

[0180] The energy consumption E_active during the active period is proportional to the time T_active during which the device opens the receiver to communicate.

[0181] E_active = k_active * T_active

[0182] Where k_active is a constant representing the energy consumption of the device per unit time, and T_active is the time the device is in an active state, i.e., the active duration.

[0183] The energy consumption during sleep mode, E_sleep, is proportional to the time (T_sleep) it takes for the device to turn off the receiver and enter a low-power state.

[0184] E_sleep = k_sleep * T_sleep

[0185] Where k_sleep is a constant representing the energy consumption of the device per unit time, and T_sleep is the time the device is in sleep mode, which is the DRX cycle minus the on-duration.

[0186] In one embodiment, the data acquisition layer introduces a Redis message (Redis Stream) for congestion control, specifically including the following steps:

[0187] a. Creating a Stream: The data from each NB-IoT module is sent as a separate message to a unified message queue. The XADD command is used to add the data from the NB-IoT module to the Stream data stream. The key, message ID, and message content are provided. The message content is key-value data, and the ID is most often represented by *, indicating that the message ID is automatically generated by the Redis in-memory database.

[0188] b. Processing Stream Data: The data acquisition layer uses the built-in XREAD or XREADGROUP commands of the in-memory database Redis to read data from the Stream; XREADGROUP is used to handle data reading in a distributed environment; through the XREADGROUP command and consumer groups, Redis implements a message queue system, where m consumers can concurrently retrieve messages from the Redis message stream to form a consumer group. The consumer group is created by the data acquisition layer using the Redis XGROUP CREATE command. Each consumer group is named with a unique name according to the monitoring type and associated with a specific Stream through a message ID; the XGROUP CREATE command allows specifying the last read message ID of the consumer group, and newly joined consumers can start consuming from the specified position;

[0189] When a consumer reads messages from a Stream message stream using the XREADGROUP command, Redis searches for unacknowledged messages in the group and assigns them to the consumer. Different consumers use different consumer IDs to identify themselves, and each message has a globally unique ID. Redis uses the consumer ID and message ID to identify acknowledged messages. The consumer ID is automatically generated by Redis using a timestamp and sequence number. The message format is: XACK key group ID [ID ……]. The XACK command returns successfully acknowledged message data. The number of successfully acknowledged messages returned by XACK refers to the number of messages on the consumer side being consistent with the total number of messages.

[0190] d. Limit Stream Size: The size of the Stream is limited by the MAXLEN parameter (maximum message length) to prevent it from growing indefinitely. The message format is: XTRIM key MAXLEN [~] count

[0191] The data queue was adjusted and optimized using Little's Law:

[0192] L = λW

[0193] Where L represents the average queue length of the number of unprocessed messages in the Redis Stream;

[0194] λ represents the average productivity of the number of queue messages arriving at the producer per second in the Redis Stream queue;

[0195] W represents the average dwell time of a message in a Redis Stream; W is also proportional to the processing rate R of a single message: W = RT;

[0196] T represents the number of unprocessed messages preceding the current message, which needs to be improved by increasing processing speed or increasing the number of consumers;

[0197] The optimization and adjustment plan is as follows:

[0198] (1) Increase processing capacity: If the message generation rate λ is greater than the preset threshold, increase the number of consumers or optimize the processing efficiency R of consumers;

[0199] (2) Reduce waiting time: If there is a difference between the message generation rate λ and the processing rate R, the difference is large when the message generation rate and the processing rate are greater than or equal to the threshold, and dynamic adjustment is required;

[0200] Protocol parsing at the data acquisition layer refers to the protocol parsing of messages after data passes through the Stream queue. This involves splitting, verifying, and structuring data packets according to a predefined private protocol to obtain the final monitoring values.

[0201] Splitting involves dividing the received data into string arrays using commas as predefined identifiers according to the protocol. The first character represents the message ID, and the second character represents the message type. The validity of data packets within the predefined unique ID and message type is determined using the first two characters. The data is then organized into an array according to the protocol's offset and parsed sequentially. The parsing method is as follows:

[0202] During parsing, the received data is placed in an array `arr`. Each packet has a sequence number `SensorNum`, 5 data bits, and 3 checksum bits. The array `arr` is then traversed, and the offset `offset` is calculated for each packet.

[0203] offset = 3 + ( sensorNum - 1 ) * 5

[0204] The subtraction of one is due to the fact that the array index starts from 0. The array is traversed based on the calculated offset to obtain all data packets.

[0205] Verification involves outputting the parsed data to the console via log, while simultaneously monitoring the data on the instrument panel in real time to compare their consistency. The actual data V equals the collected data V'. Consistency indicates correct protocol parsing; inconsistency involves printing the data values ​​at each parsing step to determine if there are logical errors. If the code implementation is correct, Wirshark is used to capture packets and verify the original data packets. The correctness of the original data packets is determined by checking whether the target data on the actual instrument display matches the data collected and printed via log.

[0206] Structured storage involves storing the target data, after it has been split and verified, in a structured manner. A monitoring data structure is created, and the detected values ​​are mapped to data categories and key field attributes. The data is then stored in a MySQL relational database. The verified data consists of the actual analog values ​​of different monitoring items collected by the instrument and the detection item types.

[0207] In one embodiment, the SCADA monitoring layer further includes the following steps:

[0208] a. MySQL Database Storage: The data acquisition layer stores the received NB-IoT data in a MySQL database; after the data is received and parsed by the backend service, the collected data is directly stored into the MySQL database via JDBC (Java Database Connectivity);

[0209] b. Data transmission between the Open Database Connectivity (ODBC) client and the OPC server: Data is obtained from the relational database MySQL through the Open Database Connectivity (ODBC) client of the Industrial Gateway OPC Server (IGS). Data is then transmitted to the SCADA system's process database (PDB) via the standardized Open Database Connectivity (ODBC) client and the process control object linking server (OLE) through the process control object linking server (OPC Server).

[0210] c. Data processing and display of the SCADA system: In the process database PDB of the SCADA system, AI analog point points are created. The AI ​​analog point point is a point point type that is input by AI analog signal and is used to receive continuously changing analog signals. The point point is a unique address or name used to identify and represent a data value. Each analog or digital quantity has a unique point point so that the system can accurately identify and access the data.

[0211] Simultaneously, set parameters such as the refresh frequency and upper and lower limits of the monitoring points. After setting, in the SCADA screen, use the OCX control and OLE object to set its data source attribute value to the monitoring point identifier, obtain the target monitoring data from the PDB process database, and display the target monitoring data in real time on the iFIX configuration interface of the configuration software through data link technology.

[0212] This invention provides a watershed water environment monitoring system based on NB-IoT and SCADA, solving the problems of high monitoring cost, small coverage, limited number of connected devices, and low data utilization in existing watershed water environment monitoring technologies. The system mainly consists of a data acquisition module that adds NB-IoT modules to existing online instruments for terminal data acquisition; a data transmission and processing module that receives and processes the terminal data from the NB-IoT modules to obtain target data, and transmits the target data to the SCADA system's process database (PDB) in real time; and a data display module that presents the target data to the user in the SCADA system through object links and configuration, realizing real-time remote monitoring, data analysis and optimization, diversified data presentation, and production process linkage functions.

[0213] Example 1

[0214] This invention aims to provide a watershed water environment monitoring system based on NB-IoT and SCADA. The front-end online instruments utilize NB-IoT narrowband IoT communication technology to transmit data from the city's public network to a unified internal data acquisition service platform via base stations. Upon receiving the data, the service performs congestion processing and protocol parsing before storing the monitoring data in a database. Each monitoring substation transmits data from the OPC gateway to the SCADA process database via the IGS ODBC Client, and then presents the data to users in real time through OLE objects, data links, and other technologies. Ultimately, the SCADA system receives and processes the monitoring data from the online instruments in real time, enabling remote monitoring and management, improving monitoring efficiency and accuracy, and maximizing data value.

[0215] Watershed water environment monitoring systems based on NB-IoT and SCADA systems, such as Figure 1As shown, in terms of data acquisition, traditional online instruments are customized with extended NB-IoT modules, and network conditions are provided through IoT cards. For data transmission and processing, an IoT data acquisition service is developed, receiving instrument data through a unified external port. After a series of processing steps, the collected data is stored in a relational database. Each substation directly connects to the data table through the ODBC Client (Open Database Connectivity) of the IGS (Industrial Gateway OPC Server), transmitting the data in real time to the SCADA's PDB (Process Database). For data display, the data is then presented to users through object links and configuration. Furthermore, the SCADA system performs data analysis, optimization, and configuration operations, linking it with the entire production process to achieve higher data utilization value.

[0216] 1. Data Collection

[0217] Regarding terminal data acquisition, an NB-IoT module is added to the existing online meters. The main process is as follows:

[0218] like Figure 2 The flowchart shown is for the expansion of the NB-IoT module.

[0219] (1) Module Selection: When selecting an NB-IoT module, key parameters need to be considered, including data transmission rate, power consumption, RF performance, size, and temperature range. Network compatibility also needs to be considered, such as whether it supports the NB-IoT frequency band in the region. Additionally, the module needs to have an interface compatible with online instruments, such as UART (Universal Asynchronous Receiver-Transmitter) or SPI (Serial Peripheral Interface), for data transmission.

[0220] Taking a combustible gas detection instrument as an example, this invention extends the Kernok MOT-500 instrument by installing an NB861 NB-IoT module. The parameters of the MOT-500 gas detection instrument are shown in Table 1 below.

[0221] Table 1 shows the parameters of the MOT-500 gas detection instrument.

[0222]

[0223] Based on this, the NB-861 module was selected as the NB-IoT extension. The NB861 series modules are globally leading NB-IoT wireless communication modules, compliant with 3GPP standards, supporting Band 05 and Band 08 frequency bands, and featuring small size, low power consumption, long transmission distance, and strong anti-interference capabilities. Because the NB861 module's ultra-small form factor can meet the requirements of almost all IoT applications, it can be easily embedded into other product applications. A SIM card is inserted through the SIM interface to provide the network environment for the module. Key parameters are as follows:

[0224] ◆ Ultra-low power consumption: 1.5uA typically

[0225] ◆ Operating voltage: NB861 RAC VBAT 2.2V~4.2V (Tye: 3.6V)

[0226] ◆ Transmit power: 23dBm±2dB (Max), maximum link budget improved by 20dB compared to GSM or LTE, maximum coupling loss MCL 164dB

[0227] ◆ Provides an external SIM card interface

[0228] ◆ Supports 3GPP Rel.13 / 14 NB-IoT radio communication interface and protocol

[0229] ◆ Supports Single-Tone, subcarrier 15kHz / 3.75kHz

[0230] ◆ Supports Multi-Tone, subcarrier 15kHz

[0231] ◆ Embedded network protocol stacks such as UDP, IP, and COAP

[0232] (2) Hardware Connection: Connect the selected NB-IoT module to the online instrument. First, design an interface circuit that can convert the data signals from the online instrument into signals acceptable to the NB-IoT module. This is achieved using an analog-to-digital converter (ADC), which converts the analog signals acquired by the online instrument into digital representation, i.e., binary form. Next, find a suitable location on the instrument to install the module, which may require modifications to the instrument's mechanical structure. Finally, connect the module to the instrument via the interface circuit and connect the power supply.

[0233] In the combustible gas detection instrument in this example, according to the module and equipment parameters, the main power supply is 24V, and the NB module is powered by 3.6V.

[0234] (3) Software Integration: This step mainly involves embedded programming. First, support for the NB-IoT module needs to be added to the instrument's control software, such as initializing the module, setting parameters, and processing the module's signals. Then, data processing code needs to be written. First, data is read from the instrument using communication interfaces (UART (Universal Asynchronous Receiver-Transmitter) and SPI (Serial Peripheral Interface)). Ensure that the communication parameters and protocols are set correctly to ensure that the data is correctly acquired. Next, the acquired raw data is processed and formatted. This includes unit conversion, precision processing, and data compensation to ensure that the data meets the required standards and range. Finally, the data is encapsulated into data packets that can be transmitted over the NB-IoT network. The encapsulation process includes packaging the data into a specific data format, usually binary, for transmission over the network. This code needs to be able to encapsulate the instrument's monitoring data into data packets that can be transmitted over the NB-IoT network, and also needs to be able to process the received data packets. This code is written using embedded programming languages ​​such as C and C++. Finally, at the upper layer, JAVA is used for software-level integration testing.

[0235] In the above example of combustible gas meter, the upper-layer software service uses JAVA SpringBoot+Netty to build an MQTT service to receive reported analog data such as combustible gas, temperature, and humidity detected by the online meter. The port for receiving external data is configured by writing an application.yml file, and the received messages are decoded according to a predefined protocol (using offsets to parse the value of each bit one by one) and finally stored in the database.

[0236] (4) Testing and Verification: After completing hardware access and software integration, a series of tests and verifications are conducted to ensure the system functions properly. This may include functional testing, performance testing, stability testing, etc. For example, the system can be checked to see if it can send and receive data normally by simulating real-world conditions. If any problems are found, it may be necessary to go back to the previous steps for modification and adjustment.

[0237] After integrating the NB-IoT module with the online instrument, and utilizing the network conditions provided by the IoT card, data can be transmitted to the nearest base station via the NB-IoT network. For NB-IoT communication, DRX mode is typically used (PSM mode can be selected if power saving is a priority, depending on the site conditions). A schematic diagram of this mode is shown below:

[0238] like Figure 3 The diagram shown illustrates the operation of DRX mode.

[0239] DRX mode is an energy-saving mechanism primarily used to reduce device power consumption when idle or connected. In DRX mode, the device does not continuously receive signals; instead, it turns on its receiver for a predetermined period (the DRX cycle) to check for incoming data. If data is received, the device remains in receiving mode; otherwise, it turns off its receiver and enters a low-power state.

[0240] DRX mode has two main components:

[0241] On-Duration: This is the period during which the device turns on the receiver and receives potential downlink transmissions. During this period, the device consumes a significant amount of power.

[0242] DRX Inactivity Timer: This timer starts counting down after the device receives data during the on-duration period. When the timer reaches the predetermined time, the device will turn off the receiver and enter a low-power state.

[0243] By adjusting these two parameters, the device's power consumption and latency can be set. Lower power consumption can be achieved by increasing the DRX cycle; lower data transmission latency can be achieved by decreasing the DRX cycle. Total energy consumption: E_total = E_active + E_sleep. In the above formula, the energy consumption during the active period is proportional to the time the device turns on the receiver for communication, while the energy consumption during the sleep period is proportional to the time the device turns off the receiver and enters a low-power state.

[0244] The energy consumption during the active period (E_active) is proportional to the time the device uses the receiver to communicate (T_active):

[0245] E_active = k_active * T_active

[0246] Where k_active is a constant representing the energy consumption of the device per unit time, and T_active is the time the device is in an active state, i.e., On-Duration.

[0247] The energy consumption during sleep (E_sleep) is proportional to the time (T_sleep) for the device to turn off the receiver and enter a low-power state:

[0248] E_sleep = k_sleep * T_sleep

[0249] Here, k_sleep is a constant representing the energy consumption of the device per unit time, and T_sleep is the time the device is in sleep mode, which is the DRX cycle minus the On-Duration (activation duration).

[0250] Finally, parameters such as IP address, port number, and message reporting time interval are set in the table header. The IP address and port number are the external network addresses and ports exposed by the Java-based data collection service used in the previous software integration step.

[0251] Once the settings are complete, the collected data will be automatically pushed to the aforementioned data acquisition service. This service will receive and parse the completed instrument monitoring data, such as... Figure 13 As shown, the ID indicates the instrument's installation location:

[0252] This completes the extended installation and data collection and reporting based on the NB-IoT module. By using NB-IoT technology, a wider coverage area and more devices can be connected. NB-IoT supports simultaneous access of a large number of devices, which helps improve the density and coverage of the monitoring network. This directly solves the technical problems of limited coverage and a limited number of connected devices in traditional water environment monitoring networks. Furthermore, by utilizing the low-power characteristics of NB-IoT devices, specifically through DRX (Discontinuous Reception) mode, NB-IoT devices can enter a low-power state when not receiving or transmitting data, thus significantly extending the device's operating time. This solves the problem of high energy consumption and the need for frequent battery or power supply replacements in traditional monitoring equipment.

[0253] 3. Data transmission processing

[0254] After the NB module is integrated into the instrument to collect data, the data needs to be received, processed, and transmitted to SCADA for better real-time monitoring and data utilization. The overall technical architecture of the system of this invention is as follows: Figure 4 As shown:

[0255] The overall system architecture includes a hardware device layer, a data acquisition layer, and a SCADA monitoring layer, as detailed below:

[0256] 1) Hardware device layer:

[0257] The physical layer, or physical layer, primarily comprises online monitoring instruments with NB-IoT modules. It is applicable to various fields of water environment monitoring, including but not limited to gas, temperature, humidity, electricity meters, and water quality. It is a crucial layer in the entire architecture and the first layer where the system interacts with the physical world. Figure 5 The hardware layer data acquisition process diagram shown below illustrates the workflow as follows:

[0258] At this layer, after the target object passes through various sensors, it first undergoes physical measurement, converting the physical quantity into a measurable signal. Following the physical measurement, data conversion occurs, using an analog-to-digital converter (ADC) to convert the continuous analog signal into a digital signal, enabling the data to be processed by other digital systems. The digital signal is then sent to a microprocessor for data processing, which may include signal filtering, error correction, and data compression. This process involves converting the data into a specific communication protocol format for wireless transmission. The processed data is then transmitted via NB-IoT modules for data communication.

[0259] 2) Data Acquisition Layer:

[0260] This layer is primarily used to receive, process, parse, and store data transmitted from devices. To handle large volumes of device data reports, this layer introduces Redis Streams for congestion control. The main process is as follows:

[0261] like Figure 6 The diagram below shows the data receiving process of a combustible gas instrument.

[0262] (1) Data reception

[0263] In this invention, data packets transmitted via NB-IoT are encapsulated using MQTT (Message Queuing Telemetry Transport), a lightweight publish / subscribe messaging protocol that uses a binary message format.

[0264] The following is a simplified MQTT header:

[0265] Fixed header:

[0266] - Control message type (4 bits): 0x01 (CONNECT)

[0267] - Remaining length (variable length, 1-4 bytes)

[0268] Variable header:

[0269] - Protocol name length (2 bytes)

[0270] - Protocol name (UTF-8 encoding)

[0271] - Protocol level (1 byte)

[0272] - Connection flag (1 byte)

[0273] - Keep-on time (2 bytes)

[0274] - Client identifier length (2 bytes)

[0275] - Client identifier (UTF-8 encoded)

[0276] Using the MQTT protocol to encapsulate and process data in NB-IoT online meter data communication offers advantages such as lightweight processing, support for offline messaging and persistent dialogue, and network efficiency. Due to its lightweight and efficient data distribution mechanism, MQTT saves more network bandwidth and battery life than other protocols, which is especially important for NB-IoT devices.

[0277] In this invention, such as Figure 7 The diagram illustrates the working principle of MQTT. It shows how to build an MQTT (Message Queuing Telemetry Transport) service using the Netty framework. Netty is a high-performance, asynchronous event-driven network application framework that supports multiple protocols. It employs high-performance designs and implementations such as zero-copy and asynchronous communication, resulting in excellent performance when handling high-concurrency, large-volume network communication. Furthermore, Netty's core is based on an asynchronous event-driven design pattern, enabling it to handle high-concurrency connections and message processing. It is particularly suitable for handling publish / subscribe message transmission protocols like MQTT, solving the problem of traditional data acquisition methods failing to handle high concurrency and timely data reporting in complex scenarios with a large number of devices.

[0278] The following is the process and key implementation steps for building an MQTT service based on a Java-based data acquisition service, as illustrated in this example:

[0279] ① Introduce Netty and MQTT dependencies. Introduce the Netty framework and MQTT dependencies into the JAVA project and specify the corresponding version numbers. The dependencies are "io.netty 4.1.54.Final" and "io.moquette 0.12.1" respectively.

[0280] ② Use "initChannel" to initialize and create the MQTT server, and add encoders, decoders, consumers, etc. using the "addlast" method.

[0281] ③ Implement the “channelRead0” method, create an MQTT processor, and write processing methods for conditions such as “handling connection requests”, “handling subscription requests”, “handling unsubscribe requests”, and “handling message publishing requests”.

[0282] (2) Congestion handling

[0283] Because there may be a large number of online devices in water environment monitoring, and each device has a frequent data collection cycle, a large amount of field data may be reported at the same time. Therefore, this invention introduces congestion control on top of data access. After the data is processed by Netty+MQTT in the previous step, it is pushed to the congestion handling module for message distribution. Congestion control is implemented using RedisStream.

[0284] Redis Stream is a new data type introduced in Redis 5.0. It can be used to implement persistent message queues. Compared to other queue technologies, it has more powerful and flexible features, including but not limited to:

[0285] • Generation of message ID serialization

[0286] Message traversal

[0287] • Blocking and non-blocking message reading

[0288] • Grouped consumption of messages

[0289] Handling of incomplete messages

[0290] Message queue monitoring

[0291] In this invention, using Redis Stream for congestion control involves the following steps:

[0292] like Figure 8 The diagram shows the Redis Stream processing flow.

[0293] a. Creating a Stream: Data from each NB-IoT device can be sent as a separate message to a unified Stream (data stream channel). Device data can be added to a Stream using the XADD command.

[0294] The syntax format is as follows:

[0295] XADD key ID field string [field string ...]

[0296] You need to provide a key, a message ID scheme, and message content, where the message content is key-value data. The ID, most commonly using *, indicates a message ID generated by Redis. The field string [field string] represents the current message content, consisting of one or more key-value pairs. Here, the value is the original message message reported via MQTT.

[0297] b. Stream Data Processing: The data acquisition layer can use the XREAD or XREADGROUP commands to read data from the stream. Using XREADGROUP allows for better handling of data reading in a distributed environment. The syntax is as follows:

[0298] XREAD [COUNT count] [BLOCK milliseconds]STREAMS key [key ...] ID [ID...]

[0299] in:

[0300] - [COUNT count], used to limit the number of messages retrieved.

[0301] - [BLOCK milliseconds] is used to set XREAD to blocking mode; the default is non-blocking mode.

[0302] - ID, used to set the message ID from which to start reading. Use 0 to indicate starting from the first message. Message queue IDs are monotonically increasing, so by setting the starting point, you can read backwards. In blocking mode, you can use $ to represent the latest message ID. ($ is meaningless in non-blocking mode).

[0303] XRED reads messages in both blocking and non-blocking modes. The BLOCK option indicates blocking mode, and the blocking duration needs to be set. In non-blocking mode, it returns immediately after reading (even if there are no messages), while in blocking mode, it blocks and waits if no content is read.

[0304] This invention uses the Block mode, with $ as the ID, to indicate reading the latest message. If there is no message, the command is blocked and waiting. If other clients append messages to the queue during the waiting process, the message will be read immediately. XADD is responsible for generating messages, and XREAD is responsible for consuming messages.

[0305] c. Message Acknowledgment: After processing a message, use the XACK command to acknowledge that the message has been processed. This way, if one service instance fails, other service instances can take over and process unacknowledged messages. The message format is as follows:

[0306] XACK key group ID [ID ...]

[0307] This command returns the number of successfully acknowledged messages. Some message IDs may no longer be part of PEL (e.g., because they have already been acknowledged), and XACK will not count them in the number of successfully acknowledged messages.

[0308] d. Limit Stream Size: The size of the Stream can be limited using the MAXLEN parameter. This prevents the Stream from growing indefinitely. The message format is as follows:

[0309] XTRIM key MAXLEN [~] count

[0310] This invention adjusts and optimizes the data queue by referencing Little's Law:

[0311] L = λW

[0312] Average queue length (L): This represents the number of unprocessed messages in the Redis Stream. A sustained increase in this number may indicate insufficient system processing capacity or a mismatch between the rates of producers (NB-IoT devices producing messages) and consumers (the data acquisition layer processing messages). This may require addressing the issue by increasing the number of consumers or optimizing processing efficiency.

[0313] Average arrival rate (λ): The number of messages arriving in the Redis Stream per second, i.e., the producer's production rate. You need to design and adjust the number of consumers and their processing capacity based on this rate to avoid system congestion.

[0314] Average Dwell Time (W): The average time a message spends waiting to be processed in a Redis Stream. If this time is too long, it may affect the system's real-time performance, requiring improvement through increasing processing speed or the number of consumers.

[0315] The optimization and adjustment plan is as follows:

[0316] Introducing R (processing rate of a single message): The larger R is, the shorter the time W that a message stays in the queue, and the more new messages can be received. The specific adjustment method is as follows:

[0317] a) Increase processing capacity: If the message generation rate (λ) is high, resulting in an increase in the number of messages in the queue, increase the processing rate (R), that is, increase the speed of message processing; this can be achieved by increasing the number of consumers or optimizing the processing efficiency of consumers.

[0318] b) Reduce waiting time: If there is a large difference between the message generation rate (λ) and the processing rate (R), resulting in an excessively long average waiting time (W), the following measures can be taken to reduce the waiting time:

[0319] c) Improve processing efficiency (R): Optimize processing logic, reduce message processing time, or use parallel processing techniques.

[0320] d) Increase the number of consumers: Increase the number of consumers to distribute messages to more consumers for concurrent processing.

[0321] e) Adjust message distribution strategy: Optimize message distribution strategy based on message importance or priority so that important messages are processed faster.

[0322] f) Balancing production and consumption rates: In message queuing systems, balancing message production and consumption rates is an important optimization strategy. If the message production rate (λ) and consumption rate (R) are kept relatively balanced, queue length and waiting time can be reduced, improving overall performance.

[0323] By using Redis Streams, the system can achieve better data persistence, reliability, and distributed processing capabilities when handling large amounts of NB-IoT device data, while also managing memory resources more effectively.

[0324] (3) Protocol parsing

[0325] After the data passes through the Stream queue, the message protocol is parsed. The data packets are split, verified, and structured according to the predefined private protocol to obtain the final monitoring value.

[0326] Splitting: The received data is split into a string array according to the identifier (",") agreed upon in the protocol. The first character represents the message ID and the second character represents the message type. The validity of the data packet is determined by whether the first two characters are within the predefined enumeration range. Then, the array is parsed one by one according to the offset of the protocol.

[0327] Verification: Output the parsed data to the console via log, and simultaneously view the data on the instrument panel in real time to compare whether the data is consistent.

[0328] Structured storage: The split and verified data is stored in a structured manner. An instrument data class is defined, and key fields such as monitoring items, real-time values, units, and reporting times are added. The parsed data is then serialized into this structure for subsequent storage. For example: Define an instrument data class, add key fields such as monitoring items, real-time values, units, and reporting times, and serialize the parsed data into this structure.

[0329] In the example of combustible gas meters, it is necessary to parse the ID (used to distinguish the installation location), Type (data type), Value (monitoring value), and other fields of the original message one by one. During parsing, the received data is placed in an array arr, with each packet having a sequence number of SensorNum, 5 data bits, and 3 check bits. Then, the array arr is traversed, and the offset is calculated for each step.

[0330] offset = 3 + ( sensorNum - 1 ) * 5

[0331] The subtraction of one is due to the fact that the array index starts from 0. The array is traversed based on the calculated offset to obtain all data packets.

[0332] This layer leverages the MQTT+Netty framework, coupled with Redis-based congestion control, enabling data to be transmitted quickly and efficiently from NB-IoT devices to the server for processing. This beneficial effect solves the problems of low data transmission and processing efficiency, and potential data loss or delays when dealing with large data volumes.

[0333] 3) SCADA monitoring layer

[0334] After the first two stages, the field data has been collected and reported to the data acquisition service via the NB-IoT module. The SCADA monitoring layer mainly uses an ODBC Client (Open Database Connectivity) to transmit data from MySQL through an OPC Server (OLE for Process Control Server) to the SCADA's PDB (Process Database). Finally, the data is presented on the configuration interface through various data links, solving the data integration problem between SCADA and relational databases. The data collected from this source is then applied to higher-level SCADA systems to achieve higher-level monitoring and control. The main key steps include:

[0335] ① MySQL Database Storage: First, the data acquisition layer stores the received NB-IoT data in a MySQL database. MySQL is a relational database, and its technological advantages include high-efficiency data storage and query performance, flexible data structures, and broad support for the SQL standard.

[0336] After the data is received by the second stage data acquisition layer, it is directly stored in MySQL via JDBC (Java Database Connectivity). Taking combustible gas monitoring data as an example, a database idata and a data table zxyb are created in MySQL. The data table 1 contains the design monitoring data. The MySQL data table structure is as follows:

[0337]

[0338] Among them, the ID is consistent with the ID set in the online instrument and is globally unique. The name differentiates the types of reported data, and other fields are added according to the detection situation. The finally reported monitoring data is stored in Data Table 2, and the data in Table 2 is as follows:

[0339]

[0340] ② Data transmission between ODBC Client and OPC Server: The ODBC Client of IGS retrieves data from the MySQL database. By using standardized ODBC and OPC technologies, the system can be easily integrated with other industrial devices and systems, which is also beneficial for future expansion and upgrade; finally, the data is transmitted to the PDB process database of the SCADA system through the OPC Server. In this step, both the ODBC Client and the OPC Server act as intermediate data transmitters. Their technical advantages include unified data interfaces and standardized transmission protocols, which help to reduce the complexity of system integration. The key configuration of the ODBC Client is as Figure 10 shown;

[0341] The real-time data finally transmitted to the OPC Server through ODBC is as Figure 11 shown;

[0342] ③ Data processing and display of the SCADA system: Finally, the SCADA system creates AI analog quantity points and retrieves data from the PDB process database, and presents the data in real time on the ifix configuration interface through technologies such as data linking. The technical advantages of the SCADA system include real-time data processing and display capabilities, powerful fault diagnosis and operation optimization functions, and extensive industrial application support.

[0343] Through this series of technical steps, the present invention realizes the data circulation from NB-IoT devices to the SCADA system, thereby achieving real-time remote control and management of water environment monitoring. Its advantages include real-time performance, remote management, data statistics and analysis, easy expansion and integration, etc.

[0344] 3. Data display

[0345] The SCADA system is the core part of the industrial automation system, and its data display and utilization functions are very powerful. After the data reaches the SCADA through the above technical solutions, the present invention demonstrates and utilizes it from the following aspects:

[0346] 1) Combining monitoring data with the distributed SCADA architecture: Optimize and control the entire production process, and then achieve the linkage of the entire production process. As Figure 9 shown, the application architecture diagram of the distributed SCADA and NB-IoT is as follows:

[0347] Device Layer: Also known as the field device layer. This layer contains a wide variety of devices, including online instruments, pumps, valves, and other industrial equipment. These devices are the basic units in the production process, capable of collecting, receiving, and processing information. For example, the sensors in online instruments can measure physical quantities such as temperature, pressure, and humidity.

[0348] Data Acquisition Service: The main task of the data acquisition service is to collect data generated at the device layer. This includes real-time monitoring data collected from various sensors, as well as information such as device status and fault codes. Data acquisition can be accomplished via wired or wireless communication, using protocols such as Modbus, PROFIBUS, and Ethernet / IP. Components at the data acquisition layer include PLCs (Programmable Logic Controllers), RTUs (Remote Terminal Units), and other data acquisition devices. This data is ultimately received by the server through the IGS OPCServer.

[0349] Substations: In this distributed SCADA system, substations serve as data aggregation and preliminary processing stations. Substations are typically located one level above the equipment or data acquisition layer, caching, preprocessing, and performing preliminary analysis and display of the collected data. They are distributed across different geographical locations, and each substation has its own independent SCADA operator station to collect real-time monitoring data within its site. A project generally has multiple substations.

[0350] Central Station: The central station is the core of the SCADA system. It is responsible for receiving all data sent by the substations and also directly collecting real-time data from each substation via IGS. The central station can monitor and control the equipment of all substations. Each sub-control center is responsible for collecting data within its own area, which is ultimately fed into the central station. The central station employs a primary / backup structure to ensure data security. Monitoring and operation are ultimately performed through multiple operator stations (clients). Furthermore, by utilizing the data collected by this invention and combining it with remote SCADA control, further automated control based on real-time data can be achieved. The central station is equipped with powerful computing resources and large-capacity storage resources.

[0351] 2) Real-time Data Display: The SCADA system can display data collected from various online instruments in real time. This real-time display function helps maintenance personnel immediately understand the current status of the system and make necessary adjustments in a timely manner. This invention mainly uses technologies such as OCX controls, OLE objects, and data links to display the associated data (e.g., ZXYB.CH4.F_CV represents the real-time data value of CH4 transmitted from the online instrument, where F_CV is a fixed suffix for real-time data in the configuration software, and the suffix varies depending on the configuration software).

[0352] Data processing and display of the SCADA system: Finally, in the SCADA system's process database (PDB), AI analog input points are created (AI stands for Analog Input. This type of point is used to receive continuously changing analog signals; a point is a unique address or name used to identify and represent a data value. Each analog or digital quantity has a unique point so that the system can accurately identify and access the data. For example, the point corresponding to the value collected by level gauge 1 in pump station 1 is: ZXYB.JSBF1.YW1, where ZXYB represents that the device type corresponding to this point is an online instrument device, JSBF1 represents pump station 1, and YW1 represents the data of level gauge 1). Simultaneously, parameters such as the point's refresh rate and upper and lower limits are set. After setting, the SCADA screen is developed. In the screen, the data source attribute value is set to the above point label using OCX controls, OLE objects, etc., to obtain the monitoring data from the process database and finally display it in real time in the configuration software IFIS.

[0353] 3) Historical Data Storage and Playback: SCADA systems can store large amounts of historical data and easily replay it. This is crucial for system fault diagnosis, performance analysis, and optimization. This invention uses a Historian historical database to support the collection, storage, analysis, and application of historical data. Its core idea is to compress data that maintains a consistent trend. Only when data changes exceed a certain threshold will a new data point be stored (e.g., real-time and historical monitoring data required for SCADA historical curves, periodically collected monitoring values ​​required for user reports, etc.). The compression principle is as follows: compress data that maintains a consistent trend; only when data changes exceed a certain threshold will a new data point be stored. For example, if the acceptable data fluctuation threshold is set to 0.5, and the instrument's first reported data is 12.2, and the second is 12.3, then 12.3 differs from the previous monitoring value by 0.1, which is less than the threshold, so no storage is needed. Only when the monitoring value is >= 12.7 or <= 11.8 will it be treated as a new acquired value and stored.

[0354] Define a compression factor C (i.e., the threshold mentioned above), and calculate the slope for data point X:

[0355] kx = (Yx - Yb) / (Xx - Xb)

[0356] If |kx - k|>C, then store point X and use X as the new starting point; otherwise, ignore point X.

[0357] kx: Represents the slope between data points. In the rotating door compression algorithm, the slope is used to determine whether a data point should be kept or discarded.

[0358] Yx: Represents the Y-axis value of the current data point, which is usually the data value to be stored.

[0359] Yb: Represents the Y-axis value of the previous retained data point, also known as the "reference point". It is the previous retained data point of the current data point.

[0360] Xx: Represents the X-axis value of the current data point, usually a timestamp or the data point's sequence number.

[0361] Xb: Represents the X-axis value of the previous retained data point, also known as the "baseline point". It is the timestamp or sequence number of the previous retained data point of the current data point.

[0362] Taking combustible gas detection data as an example, create new historical data tags and add them to the historical database. The key configurations for historical data storage are as follows, mainly targeting parameters such as tag name, collection period, and unit. Figure 12 As shown,

[0363] Once added, the tags will be compressed and stored at the configured intervals, ultimately providing data support to upper-layer services via an external API. Utilizing the Historian historical database, long-term monitoring data can be stored efficiently, and a rotating door compression algorithm is employed for efficient storage. This solves the problems of long-term storage and efficient utilization of monitoring data.

[0364] This invention discloses a watershed water environment monitoring system based on NB-IoT and SCADA, which solves the problems of high monitoring cost, small coverage, limited number of connected devices, low data utilization, and inadequate real-time performance and accuracy of data processing and display in existing watershed water environment monitoring technologies. Through deep integration of SCADA and NB-IoT technologies and architectures, it achieves stronger coverage and allows for more device access: by using NB-IoT technology, a wider coverage area and more device access are achieved; NB-IoT supports simultaneous access of a large number of devices, which helps to improve the density and coverage of the monitoring network, solving the technical problems of limited coverage and limited number of connected devices in traditional water environment monitoring networks; NB-IoT devices have low power consumption characteristics, and through DRX mode, NB-IoT devices can enter a low-power state when not receiving or sending data, resulting in low power consumption. Energy efficiency and continuous operation solve the problems of high energy consumption and frequent battery or power supply replacement required by traditional monitoring equipment. Utilizing the MQTT protocol and Netty framework, data can be transmitted quickly and efficiently from NB-IoT devices to the server at the data acquisition layer for processing. Efficient and stable data transmission and processing solve the problems of low data transmission and processing efficiency, which may lead to data loss or delay. In addition, deep integration with the distributed SCADA system makes the entire data processing process more stable and fault-tolerant. Through the SCADA system, monitoring data from online instruments can be received and processed in real time, enabling remote monitoring and management, improving monitoring efficiency and accuracy, and performing statistical analysis, fault diagnosis, and operational optimization. The Historian historical database can efficiently store long-term monitoring data, and the rotating door compression algorithm is used for efficient storage.

Claims

1. A watershed water environment monitoring system based on NB-IoT and SCADA, characterized in that, The system includes a data acquisition module, a data transmission and processing module, and a data display module; The data acquisition module is a terminal data acquisition module that adds an NB-IoT module to the existing online instrument. The data transmission processing module is used to receive terminal data from the NB-IoT module, process it to obtain target data, and store the target data in a relational database. There are n substations that directly associate the target data table through the open database connection client ODBC of the industrial gateway OPC server, and transmit the target data to the process database PDB of the SCADA system in real time. The data transmission processing module includes a data acquisition layer and a SCADA monitoring layer; The data acquisition layer receives, processes, and parses the data transmitted from the device, and simultaneously reports the processed device data. The data acquisition layer also incorporates a Redis message stream for congestion control. This congestion control process using the Redis message stream includes the following steps: a. Creating a Stream: The data from each NB-IoT module is sent as a separate message to a unified message queue. The XADD command is used to add the data from the NB-IoT module to the Stream data stream. The key, message ID, and message content are provided. The message content is key-value data, and the ID is most often represented by *, indicating that the message ID is automatically generated by the Redis in-memory database. b. Processing Stream Data: The data acquisition layer uses the built-in XREAD or XREADGROUP commands of the in-memory database Redis to read data from the Stream; XREADGROUP is used to handle data reading in a distributed environment; through the XREADGROUP command and consumer groups, Redis implements a message queue system, where m consumers can concurrently retrieve messages from the Redis message stream to form a consumer group. The consumer group is created by the data acquisition layer using the Redis XGROUP CREATE command. Each consumer group is named with a unique name according to the monitoring type and associated with a specific Stream through a message ID; the XGROUPCREATE command allows specifying the last read message ID of the consumer group, and newly joined consumers can start consuming from the specified position; c. When a consumer reads a message from the Stream message stream using the XREADGROUP command, Redis searches for unacknowledged messages in the group and assigns them to the consumer. Different consumers use different consumer IDs to identify themselves, and each message has a globally unique ID. Redis uses the consumer ID and message ID to identify acknowledged messages. The consumer ID is automatically generated by Redis using a timestamp and sequence number. The message format is: XACK key group ID [ID ……]. The XACK command returns successfully acknowledged message data. The number of successfully acknowledged messages returned by XACK refers to the number of messages on the consumer side being consistent with the total number of messages. d. Limit Stream Size: The size of the Stream is limited by the MAXLEN parameter (maximum message length) to prevent it from growing indefinitely. The message format is: XTRIM key MAXLEN [~] count The data queue was adjusted and optimized using Little's Law: L = λW Where L represents the average queue length of the number of unprocessed messages in the Redis Stream; λ represents the average productivity of the number of queue messages arriving at the producer per second in the Redis Stream queue; W represents the average dwell time of a message in a Redis Stream; W is also proportional to the processing rate R of a single message: W = RT; T represents the number of unprocessed messages preceding the current message, which needs to be improved by increasing processing speed or increasing the number of consumers; The optimization and adjustment plan is as follows: (1) Increase processing capacity: If the message generation rate λ is greater than the preset threshold, increase the number of consumers or optimize the processing efficiency R of consumers; (2) Reduce waiting time: If there is a difference between the message generation rate λ and the processing rate R, the difference is large when the message generation rate and the processing rate are greater than or equal to the threshold, and dynamic adjustment is required; The protocol parsing of the data acquisition layer refers to the protocol parsing of messages after the data passes through the Stream queue. This involves splitting, verifying, and structuring data packets according to a predefined private protocol to obtain the final monitoring values. The splitting process involves dividing the received data into string arrays using commas as predefined identifiers according to the protocol. The first character represents the message ID, and the second character represents the message type. The validity of data packets within the predefined unique ID and message type is determined using the first two characters. The data is then divided into arrays according to the protocol offsets and parsed sequentially. The parsing method is as follows: During parsing, the received data is placed in an array `arr`. Each packet has a sequence number `SensorNum`, 5 data bits, and 3 checksum bits. The array `arr` is then traversed, and the offset `offset` is calculated for each packet. offset = 3 + ( sensorNum - 1 ) * 5 The subtraction of one is due to the fact that the array index starts from 0. The array is traversed based on the calculated offset to obtain all data packets. The verification process involves outputting the parsed data to the console via log, while simultaneously monitoring the data on the instrument panel in real time and comparing the data for consistency. The actual data V equals the collected data V'. If the data matches, the protocol parsing is correct; otherwise, the data values ​​at each step of the parsing process are printed to determine if there are any logical errors. If the code implementation logic is correct, Wireshark is used to capture packets and check if the original data packets are correct. The correctness of the original data packets is determined by checking whether the target data on the actual instrument display matches the data collected and printed via log. The structuring process involves storing the split and verified target data in a structured manner, creating a monitoring data structure, mapping the detected values ​​to data categories and key field attributes, and finally storing the data in a MySQL relational database. The verified data consists of the actual analog values ​​of different monitoring items collected by the instrument and the detection item types. The SCADA monitoring layer is used to receive raw data collected by the field equipment layer and transmit it to the SCADA system. The SCADA monitoring layer connects to the client through the ODBC Client open database connection, and transmits the data from the MySQL database through the OPC Server process control object link server to the SCADA PDB process database. Finally, it is presented on the configuration interface in the form of various data links. The data display module is used to present the target data to the user on the SCADA system through object links and in a configured manner.

2. The watershed water environment monitoring system based on NB-IoT and SCADA according to claim 1, characterized in that, The data acquisition module further includes a module selection unit, a hardware access unit, a software integration unit, and a testing and verification unit; The module selection unit is used for module selection. The selected module is an NB-IoT module. When selecting an NB-IoT module, key parameters are selected, including data transmission rate, power consumption, radio frequency performance, size, and temperature range. The hardware access unit is used to connect the NB-IoT module to the online instrument through the designed interface circuit. The interface circuit converts the data signal of the online instrument into a digital signal received by the NB-IoT module. The software integration unit is used to establish a communication connection after the online instrument adds the NB-IoT module, and to process the received analog signals. The data processing adopts the following steps: Step 1: Initialize the module: Use the UART (Unified Transceiver Articulated Transceiver) or SPI (Serial Peripheral Interface) serial communication interface to physically connect the NB-IoT module to the main control system. After connection, set the baud rate, data bits, and stop bit parameters, start the network connection of the NB-IoT module, and establish a communication connection with the NB-IoT base station. Step 2: Set parameters: Configure the Access Point Name (APN) of the NB-IoT module to connect to the NB-IoT network and access the cloud server; select TCP as the transmission protocol and the corresponding port number for sending data packets to the server; then configure the data transmission frequency. Step 3: Signal processing module 101 Reads the monitoring data from the instrument's sensors, including temperature, humidity, and pressure information; The 102 monitoring data is an analog signal, which undergoes analog-to-digital (A / D) conversion. 103 calibrates, filters, and compresses the collected monitoring data as raw data, and encapsulates the instrument's monitoring data into binary data packets that are transmitted through the NB-IoT network. It also processes the received data packets. After completing hardware access and software integration, the test and verification unit performs tests and verifications, simulating real-world conditions to check whether the system can send and receive data normally. If problems are found, it returns to steps 1 and 2 for modification and adjustment. After integrating the NB-IoT module with the online instrument, the data is sent to the nearest base station through the NB-IoT communication network. The NB-IoT communication mode typically adopts the DRX mode.

3. A watershed water environment monitoring system based on NB-IoT and SCADA according to claim 1, characterized in that, The data transmission processing module also includes a hardware device layer, used to obtain physical measurement data of the monitored target through various sensors, convert the physical quantity data into measurable signal quantity data, and convert the continuous target analog signal into a target digital signal through an analog-to-digital converter (ADC). The target digital signal is then sent to a microprocessor for processing, and the processing is carried out according to the following steps: 201 signal filtering The acquired raw signals are processed to remove noise and interference to obtain the target data; the filtering method is determined according to the data type and application scenario, and the filtering method includes low-pass filtering, median filtering and high-pass filtering, wherein low-pass filtering is selected for online gas instruments; 202 Error Correction Error correction is performed on the target data using dynamic correction; the dynamic correction is to correct the collected data based on the real-time operating status or feedback data; through dynamic correction, the target data of the sensor output is adjusted in real time according to the actual situation; 203 Data Compression The target data is compressed, and the data compression includes lossy compression and lossless compression. Lossless compression is used for instrument data. 204 Data Conversion After data decompression, the original collected data is converted and encapsulated into the NB-IoT protocol data format for transmission.

4. A watershed water environment monitoring system based on NB-IoT and SCADA according to claim 1, characterized in that, The data display module also includes the following: a. Establish a monitoring data combined with a distributed SCADA architecture: The construction of the distributed SCADA architecture involves integrating the data collected by n sub-control centers within their respective site ranges into the central station. The central station is configured with enhanced redundancy for disaster recovery and prevention, and the data is ultimately displayed on the intelligent client iClient. b. Real-time data display: The SCADA system displays data collected from various online instruments in real time, using OCX controls and OLE objects, and employing data linking methods to embed and display the data. c. Historical Data Storage and Playback: The historical data stored in the SCADA system is collected, stored, and compressed using a Historian historical database. Collection refers to the real-time and historical monitoring data required for SCADA historical curves and the periodically collected monitoring values ​​required for user reports. Historical monitoring value data is compared with a threshold value for periodically collected monitoring values. When the threshold value for periodically collected monitoring values ​​exceeds a preset threshold, the target monitoring value is obtained, compressed, and stored. The threshold value is the difference between the monitoring value in the current period and the monitoring value in the previous period. The revolving door trend algorithm is used as follows: The threshold is a compression factor C. For data point X, its slope is calculated as follows: kx=(Yx-Yb) / (Xx-Xb) If |kx - k|>C, store point X and use X as the new starting point; otherwise, ignore point X. Where kx represents the slope between data points; in the rotating door compression algorithm, the slope is used to determine whether a data point should be kept or discarded. Yx represents the Y-axis value of the target data point, which is usually the data value to be stored. Yb represents the Y-axis value of the previous retained data point, which serves as the Y-axis reference point and is the previous retained data point of the target data point; Xx represents the X-axis value of the target data point, which is usually a timestamp or the serial number of the data point. Xb represents the X-axis value of the previous retained data point, serving as the X-axis reference point. It is the timestamp or sequence number of the previous retained data point of the target data point.

5. A watershed water environment monitoring system based on NB-IoT and SCADA according to claim 4, characterized in that, Creating an OCX control includes the following steps: (1) Create an OCX control: Create a custom OCX control that collects target data from the process database and displays it on the interface; (2) Integrating OCX controls: Integrating custom OCX controls into the SCADA system, embedding custom OCX controls into the graphical interface of the SCADA system through ActiveX technology; (3) Data association: Associate the OCX control with the data source of the online instrument: After dragging the target data of the OCX control to the configuration screen, set the target data attributes, select the point label stored in the SCADA process database, and associate the label with the same fixed suffix of the real-time target data; (4) Real-time update: The SCADA system regularly obtains the latest target data from online instruments and updates it in real time through the OCX control; the target data displayed on the interface is refreshed periodically.

6. A watershed water environment monitoring system based on NB-IoT and SCADA according to claim 4, characterized in that, The steps for creating an OLE object are as follows: (1) Creating an OLE object: Use an application that supports OLE technology to create an OLE object, or obtain an OLE object provided by a third party; (2) Embedding OLE objects: In the graphical user interface of the SCADA system, the created OLE objects are embedded into documents or reports; users can access and control the embedded OLE objects by operating on the documents or reports. (3) Data association: The SCADA system associates OLE objects with data collected by online instruments through data linking technology, enabling OLE objects to display relevant data. Then, the charts are embedded in the reports, and the real-time target data of the online instruments are dynamically displayed. The specific steps for embedding the reports are as follows: a. Create a report: In the report editor of the SCADA system, create a new report file; b. Insert OLE object: Insert an OLE object into the report. The OLE object is the real-time target data of the data collected by the online instrument. c. Configure data link: Set the data source property of the OLE object, select the data label corresponding to the data value collected by the online instrument in the SCADA process database, associate the OLE object in the report with the source of the real-time data value, set the source property value of the OLE object to the point label in the process database, and when the configuration screen is running, poll and update the data value collected by the online instrument so that the OLE object in the report will dynamically display the real-time target data value associated with the online instrument; d. Real-time display: Establish a data link, and the OLE object in the report will refresh the target data on the screen in real time based on the monitoring target data in the SCADA process database. By recording real-time values, the historical trend of the target data can be displayed.

7. A watershed water environment monitoring system based on NB-IoT and SCADA according to claim 4, characterized in that, The data linking method includes the following steps: (1) Data source configuration: Configure the data source for communication with online instruments, set the data source and communication protocol; the data source is a sensor, a PLC programmable logic controller or other real-time data acquisition device; (2) Data association: Real-time data in the data source is associated with OCX controls or OLE objects in the graphical interface through data linking technology; so that the OCX control can display the target data collected by the online instrument in real time; (3) Real-time update: The SCADA system periodically updates the associated target data from the data source and displays it in real time through OCX controls or OLE objects.

8. A watershed water environment monitoring system based on NB-IoT and SCADA according to claim 2, characterized in that, The test and verification unit typically uses DRX mode in NB-IoT communication mode. Specifically, in DRX mode, the device does not continuously receive signals, but turns on its receiver during a predetermined DRX period to check if there is incoming data. If there is data, the device will maintain the receiving state; otherwise, the device will turn off its receiver and enter a low-power state. The main components of the DRX mode are two On-Duration activation durations and a DRX inactivity timer; On-Duration: This is the period during which the device turns on the receiver and receives downlink transmissions; during this period, the device consumes more energy. DRX Inactivity Timer: The timer starts counting down after the device receives data during the active duration period. When the timer reaches the predetermined time, the device will turn off the receiver and enter a low-power state. By adjusting these two parameters, the device's power consumption and latency can be set; if lower power consumption is needed, the DRX cycle can be increased; if lower data transmission latency is needed, the DRX cycle can be decreased; Total energy consumption: E_total = E_active + E_sleep; The energy consumption E_active during the active period is proportional to the time T_active during which the device opens the receiver to communicate. E_active = k_active * T_active Where k_active is a constant representing the energy consumption of the device per unit time, and T_active is the time the device is in an active state, i.e., the active duration. The energy consumption during sleep mode, E_sleep, is proportional to the time (T_sleep) it takes for the device to turn off the receiver and enter a low-power state. E_sleep = k_sleep * T_sleep Where k_sleep is a constant representing the energy consumption of the device per unit time, and T_sleep is the time the device is in sleep mode, which is the DRX cycle minus the on-duration.

9. A watershed water environment monitoring system based on NB-IoT and SCADA according to claim 1, characterized in that, The SCADA monitoring layer also includes the following steps: a. MySQL Database Storage: The data acquisition layer stores the received NB-IoT data in a MySQL database; after the data is received and parsed by the backend service, the collected data is directly stored in the MySQL database through a JDBC database connection; b. Data transmission between the Open Database Connectivity Client (ODBC Client) and the OPC Server (OPC Server): Data is obtained from the relational database MySQL through the Open Database Connectivity Client (ODBC Client) of the industrial gateway OPC Server (IGS). Data is then transmitted to the process database (PDB) of the SCADA system through the standardized Open Database Connectivity Client (ODBC) and the process control object link server (OLE) using the process control object link server (OPC Server). c. Data processing and display of the SCADA system: In the process database PDB of the SCADA system, AI analog point points are created. The AI ​​analog point point is a point point type that is input by AI analog signal and is used to receive continuously changing analog signals. The point point is a unique address or name used to identify and represent a data value. Each analog or digital quantity has a unique point point so that the system can accurately identify and access the data. Simultaneously, set the refresh frequency and upper and lower limit parameters of the points. After setting, in the SCADA screen, use the OCX control and OLE object to set its data source attribute value to the point identifier, obtain the target monitoring data from the PDB process database, and display the target monitoring data in real time on the configuration software ifix configuration interface through data link technology.

Images