Linux-based multi-sensor hierarchical monitoring and data synchronous processing system and method

Abstract

The invention discloses a multi-sensor hierarchical monitoring and data synchronous processing system and method based on Linux, and belongs to the technical field of embedded system data acquisition. The system comprises a multi-source data interface monitoring module, a data acquisition module, a data synchronization module and a data storage module. The method comprises the steps that firstly, the state of a multi-source sensor is monitored through a three-level layered monitoring mechanism, and abnormal events are captured in real time; secondly, the main thread dynamically adjusts a working strategy of a working thread based on an abnormal event, the working thread acquires data, stores the data into a ring buffer area and then informs the main thread and a synchronous thread, and the main thread regularly reads the data, judges an ice condition stage and dynamically adjusts the working strategy of the working thread; thirdly, the synchronization thread synchronizes the multi-source pilot frequency data based on a hardware clock source; and finally, the local edge layer and the remote center layer collaboratively store data, and provide a data access and push interface. The system reliability can be enhanced, and the system stability is improved; and high-reliability synchronous data support is provided for early warning of ice disasters.

Description

Technical Field

[0001] The present invention belongs to the technical field of embedded system data acquisition, and relates to a Linux-based multi-sensor hierarchical monitoring and data synchronization processing system and method. Background Art

[0002] Against the backdrop of global climate change and frequent extreme weather events, freezing processes in cold regions pose multiple risks. Efficient ice monitoring methods have become a core technical requirement for ensuring public safety, maintaining ecological balance, and preventing natural disasters. Frozen environments significantly impact transportation infrastructure, agricultural irrigation systems, river basin hydrological cycles, and glacier stability. River ice jams can trigger large-scale ice floods, seasonal freeze-thaw of permafrost can damage infrastructure, and dynamic changes in glacier thickness directly impact regional water resource assessments and climate modeling. Therefore, a high-precision, highly reliable ice monitoring system is crucial for disaster warning and ecological protection.

[0003] The evolution of ice conditions has significant stage characteristics and can generally be divided into the growth period, the stable sealing period, and the melting period. Among them, the melting period is the most critical period for disaster prevention and control due to the rapid deterioration of the ice structure. The monitoring system is required to have multi-parameter high-frequency sampling and high-speed data transmission capabilities to efficiently capture the most critical physical parameter mutations before the ice breaks. The "A method and system for monitoring ice conditions in pumped storage power stations" proposed by Chinese invention patent CN110595418A improves the accuracy of ice thickness measurement and realizes continuous ice thickness measurement through the coordinated monitoring of multiple sensors such as sonar sensors, radar water level gauges, temperature sensors, and water gauges; the "Online automatic monitoring device for temperature gradients and ice thickness" proposed by Chinese invention patent CN103983376A uses GPRS wireless communication to build a remote transmission channel for ice condition data, and sends the ice condition data of the monitored water area to the information processing computer in the information room to ensure the timely acquisition of ice condition data. However, the above only considers the problem of data collection and transmission of multi-sensor systems, lacks a systematic full-link monitoring mechanism, and still has the following defects in the abnormal graded response of multiple sensors, dynamic adjustment of sensor sampling frequency, and accurate synchronous processing of data:

[0004] (1) The system does not have an abnormality classification monitoring mechanism and cannot distinguish between signal-level abnormalities and equipment-level failures, resulting in error location delays and seriously restricting the real-time performance and reliability of the system;

[0005] (2) The system lacks the ability to identify ice conditions in different stages based on data characteristics. It cannot automatically determine the stage of ice conditions and complete thread scheduling based on the continuity characteristics of sensor data in the time interval. It is also unable to achieve dynamic optimization of sampling frequency and cannot meet the needs of monitoring rapidly changing ice conditions.

[0006] (3) The system faces the risk of sensor clock error amplification and misalignment of multi-source heterogeneous frequency data. In addition, the existing systems mostly adopt a single mode of local storage or direct transmission to the cloud, without implementing data hierarchical management and network disconnection and resumption mechanism. They cannot meet the dual needs of historical data tracing and real-time analysis in the ice monitoring process, which restricts the accurate construction of the prediction model for the ice melting stage. Summary of the Invention

[0007] In response to the problems existing in the existing technology, the present invention provides a Linux-based multi-sensor hierarchical monitoring and data synchronization processing system and method. Through a multi-sensor status hierarchical monitoring mechanism, a sensor sampling frequency dynamic adjustment method and a dynamic data synchronization processing strategy, the system's real-time performance, reliability and data consistency are significantly improved.

[0008] In order to achieve the above object, the technical solution adopted by the present invention is:

[0009] A Linux-based multi-sensor hierarchical monitoring and data synchronization processing system includes a multi-source data interface monitoring module, a data acquisition module, a data synchronization module, and a data storage module; specifically:

[0010] The multi-source data interface monitoring module is used to monitor the physical signals, hardware interfaces and communication link status of multi-source sensors in real time, and ensure the reliability and integrity of multi-source sensor data through a three-level hierarchical monitoring mechanism;

[0011] The data acquisition module is used to dynamically collect multi-source sensor data, adjust the data acquisition frequency according to the abnormal level and ice condition stage, and work together through the main thread and the working threads of each sensor to ensure the efficiency and real-time performance of data acquisition;

[0012] The data synchronization module is used to achieve accurate synchronization of multi-source heterogeneous frequency data. Based on the hardware clock source and the type-based interpolation algorithm, the data with different sampling rates are aligned to a unified time axis through the synchronization thread to ensure the time consistency of the data.

[0013] The data storage module is used to provide a collaborative storage architecture between the local edge layer and the remote center layer. The local edge layer uses the SQLite database to cache real-time data, and the remote center layer uses TimescaleDB to implement distributed storage. It also provides data access services through the RESTful API and WebSocket interface to achieve low-latency caching and highly reliable persistent storage of data.

[0014] Furthermore, the multi-source data interface monitoring module covers all-round monitoring of multi-source sensors from the physical signal layer, hardware interface layer to the communication link layer through a three-level hierarchical monitoring mechanism. The three-level hierarchical monitoring mechanism is implemented through the Linux kernel state bottom layer, kernel state middle layer, and user state top layer. The multi-source sensors include image acquisition sensors, water temperature sensors, ambient temperature sensors, ice thickness sensors, solar radiation sensors, wind speed sensors, water flow rate sensors, and ice layer stress sensors.

[0015] Furthermore, the data acquisition module adopts a collaborative architecture of main threads and working threads, and realizes efficient acquisition and abnormal response of multi-source sensor data through dynamic thread scheduling and adaptive acquisition strategies. The multi-source sensor data includes: image data, water temperature data, ambient temperature data, ice thickness data, solar radiation data, wind speed data, water flow rate data, and ice layer stress data.

[0016] Furthermore, the hardware clock source used by the data synchronization module is the GPS module, and the PPS hardware interrupt signal output by the GPS module every second and the UTC time parsed by the GPRMC message are used as the time reference.

[0017] Furthermore, the multi-source sensor interface types monitored by the multi-source data interface monitoring module include: UART interface, IIC interface, SPI interface, USB3.0 interface and Ethernet interface, and different interfaces are monitored from the physical signal layer, hardware interface layer and communication link layer respectively.

[0018] A Linux-based multi-sensor hierarchical monitoring and data synchronization processing method is implemented based on the above-mentioned multi-sensor hierarchical monitoring and data synchronization processing system, comprising the following steps:

[0019] Step S1: Initialize the system hardware and monitor the status of multiple sensors through a three-level hierarchical monitoring mechanism to capture abnormal events in real time. Specifically:

[0020] In step S1.1, the system loads the Linux kernel and allocates independent working threads and memory resources for the multi-source sensors, and initializes the multi-source data interface monitoring module.

[0021] Step S1.2, monitor the status of multi-source sensors through a three-level hierarchical monitoring mechanism, the bottom layer of the kernel state captures physical signal anomalies through hardware interrupts, and detects bus signal quality, physical layer transmission errors and physical connection status in real time through the clock management unit and hardware register access of the Linux kernel subsystem, and generates a first-level abnormal event; the middle layer of the kernel state detects interrupt storms through the driver level, registers interrupt processing functions in the kernel driver, counts the interrupt trigger frequency of the hardware interface, monitors the sensor chip temperature and power supply voltage anomalies, and generates a second-level abnormal event; the highest layer of the user state ensures the stability of the communication link through the heartbeat packet mechanism and dynamic bandwidth adjustment, sets a dynamic timeout response time, counts the data packet loss rate and bandwidth congestion status within a period of time, and generates a third-level abnormal event.

[0022] Step S1.3, write the first-level abnormal event, the second-level abnormal event and the third-level abnormal event into the message queue, obtain a multi-level abnormal event message queue and notify the main thread.

[0023] In step S2, the main thread dynamically adjusts the working strategy of the worker thread based on the abnormal event. The worker thread collects data and stores it in the ring buffer, notifying the main thread and synchronization thread. The main thread periodically reads data from the ring buffer to determine the ice condition stage and dynamically adjusts the working strategy of the worker thread. Specifically:

[0024] Step S2.1: The main thread receives the multi-level abnormal event message queue and determines the abnormal level of the sensor.

[0025] Step S2.2: The main thread creates an abnormal event table, records the device ID, abnormal level, and specific description of the abnormal event, and stores the abnormal event table in the data storage module.

[0026] In step S2.3, for a level 1 abnormal event, the main thread immediately stops collecting data from the corresponding sensor in the working thread and triggers a hardware reset or switches to a backup communication interface; for a level 2 abnormal event, the main thread dynamically reduces the data collection frequency of the corresponding sensor in the working thread to reduce data traffic; for a level 3 abnormal event, the main thread only allows the working thread to discard the abnormal data segment of the corresponding sensor.

[0027] In step S2.4, the worker thread establishes a ring buffer. Mutexes and conditional variables are used to secure multi-source sensor data when reading and writing it. Specifically, the worker thread collects data, adds a timestamp to the raw data, and then writes the timestamped raw data into the ring buffer. Before writing the raw data, the worker thread acquires a mutex lock, releases the mutex lock after writing the raw data, and triggers a conditional variable to notify the main thread and synchronization thread. Conditional variables are a key mechanism for inter-thread synchronization in Linux. Used in conjunction with mutexes, they primarily address inter-thread waiting and notification issues.

[0028] In step S2.5, after receiving the condition variable, the main thread acquires the mutex lock regularly, reads the ice thickness data from the ring buffer, and releases the mutex lock.

[0029] In step S2.6, the main thread determines the ice condition stage based on the ice thickness data using the following formula:

[0030]

[0031] in, Indicates the number of days of data observation set. Indicates the minimum consecutive days threshold for trend determination. Indicates the date index when traversing historical data. Indicates the current date index, Indicates the fixed measurement time every day, Indicates the sky The ice thickness measurement at the time, Indicates the sky The ice thickness measurement at the time, represents the daily growth threshold of ice thickness during the growing period, Indicates the length of the stable sealing period determination window, Indicates the ice thickness fluctuation threshold between consecutive days during the stable closure period, Indicates the daily reduction threshold of ice thickness during the ablation period.

[0032] From this we can see that if there is at least one continuous The ice thickness growth exceeded the threshold every day. , it is determined to be the growth period; if there are at least continuous The absolute value of the ice thickness change on any two consecutive days does not exceed the threshold , it is determined to be a stable closure period; if there are at least continuous The ice thickness reduction exceeded the threshold on each day , it is determined to be the ablation period.

[0033] In step S2.7, the main thread dynamically adjusts the acquisition strategy of each sensor of the working thread according to the ice condition stage determined in step S2.6. During the growth period, the working thread maintains the basic sampling rate of each sensor; during the stable sealing period, the working thread reduces the sampling rate of non-critical sensors; during the ablation period, the working thread increases the sampling rate of critical sensors. Specifically, the non-critical sensors are defined as sensors that collect data that indirectly reflects the state of the ice layer or indirectly drives changes in ice conditions, including image acquisition sensors, wind speed sensors, and water flow rate sensors. The critical sensors are defined as sensors that collect data that directly reflects the state of the ice layer or directly drives changes in ice conditions, including water temperature sensors, ambient temperature sensors, ice thickness sensors, solar radiation sensors, and ice stress sensors.

[0034] Step S3: The synchronization thread synchronizes the multi-source heterogeneous frequency data based on the hardware clock source. Specifically:

[0035] In step S3.1, the data synchronization module uses the PPS hardware interrupt signal output by the hardware clock source GPS every second and the UTC time parsed by the GPRMC message as the benchmark, calibrates the internal clocks of the system and each sensor through hardware interrupts, and generates a globally unified microsecond-level timestamp.

[0036] In step S3.2, the synchronization thread obtains the mutex lock after receiving the condition variable sent by the working thread in step S2.4, takes out the raw data of each sensor from the ring buffer according to the microsecond timestamp generated in step S3.1, and then releases the mutex lock.

[0037] In step S3.3, the image acquisition sensor, which has the highest sampling frequency, is used as the reference time axis to perform categorical interpolation on the lower-frequency data collected by other sensors. Linear interpolation is used for spatially uniform and gently varying data such as water temperature, ambient temperature, ice thickness, and solar radiation. Kriging spatial interpolation is used for spatially correlated and abrupt data changes such as wind speed, water velocity, and ice stress.

[0038] In step S3.4, the low-frequency sampling data in step S3.3 is interpolated by type and aligned to the reference time axis to generate multi-source data frames with unified time sequence, and strictly sorted by timestamps, and a synchronization data table is established to record timestamps and multi-source data frames; the synchronization data table is then stored in the data storage module, thereby achieving microsecond-level time synchronization and spatiotemporal consistency of multi-source data in a complex environment.

[0039] In step S4, the local edge layer and the remote center layer collaborate to store data and provide data access and push interfaces. Specifically:

[0040] In step S4.1, the data storage module adopts a collaborative storage architecture between the local edge layer and the remote center layer. The local edge layer uses the SQLite database to build a real-time data cache, while the remote center layer uses TimescaleDB for distributed time series data storage. All uploaded data is managed by time partition (one shard per day). The data stored in the local edge layer and the remote center layer includes the exception event table in the main thread and the synchronization data table in the synchronization thread. Atomic operations are used when storing data to ensure data integrity.

[0041] Step S4.2: When the network is disconnected, the local edge layer resumes transmission to the remote center layer based on the timestamp of the last successful synchronization, and verifies the data integrity frame by frame. If an abnormal frame is found, it will be retransmitted;

[0042] Step S4.3, set up a timed incremental synchronization mechanism, trigger an incremental synchronization task every once in a while, compare the latest synchronization timestamps of the local edge layer and the remote center layer, extract the unsynchronized data blocks to synchronize the data of the local edge layer and the remote center layer; provide data access services through RESTful API and WebSocket interface, RESTful API supports combined query (filtered by timestamp range, device ID, and anomaly level), and WebSocket interface pushes high-frequency data of the ablation period in real time, realizing full-link data management and secure access from real-time caching of the local edge layer to long-term storage of the remote center layer.

[0043] The beneficial effects of the present invention are:

[0044] (1) The present invention implements full-link fault detection from bottom-layer signal integrity to upper-layer protocol compliance through a three-level monitoring mechanism at the physical signal layer, hardware interface layer, and communication link layer, shortening the anomaly location time and significantly enhancing system reliability.

[0045] (2) The present invention eliminates the time phase deviation of multi-source heterogeneous frequency data through GPS hardware clock synchronization and type-based interpolation algorithm, providing highly reliable synchronous data support for ice disaster warning;

[0046] (3) The present invention uses an adaptive acquisition strategy to adjust the sensor sampling rate in real time according to the ice condition stage, which can reduce resource waste, improve work efficiency, and enhance system stability;

[0047] (4) The present invention stores data through a collaborative storage architecture of a local edge layer SQLite database and a remote center layer TimescaleDB database. Through incremental synchronization operations and a network-disconnected retransmission mechanism, it meets the full-scenario requirements from real-time analysis at the local edge layer to long-term tracing at the remote center layer. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] Figure 1 Flowchart of the present invention;

[0049] Figure 2 This is a flow chart of the multi-source data interface monitoring module of the present invention monitoring the multi-source sensor status through a three-level hierarchical monitoring mechanism;

[0050] Figure 3 This is a diagram of the collaborative work flow of the main thread, working thread and synchronization thread of the data acquisition module of the present invention;

[0051] Figure 4 This is a flow chart of the data synchronization module of the present invention synchronizing multi-source heterogeneous frequency data based on a hardware clock source. DETAILED DESCRIPTION

[0052] To make the objectives, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts shall fall within the scope of protection of the present invention.

[0053] The present invention provides an embedded multi-source sensor hierarchical monitoring and data synchronization storage system for ice condition monitoring and its use method. Through a multi-level monitoring mechanism of sensor status, a dynamic data synchronization strategy and an edge-center collaborative storage architecture, the system's real-time performance, reliability and data consistency are significantly improved.

[0054] like Figure 1 As shown, the specific technical solution adopted in the embodiment of the present invention includes the following steps:

[0055] Step S1, system hardware initialization, monitoring the multi-source sensor status through a three-level hierarchical monitoring mechanism, and capturing abnormal events in real time, such as Figure 2 shown. Specifically:

[0056] In step S1.1, the system loads the Linux kernel and allocates independent working threads and memory resources for the multi-source sensors, and initializes the multi-source data interface monitoring module.

[0057] Step S1.2, monitor the status of multi-source sensors through a three-level hierarchical monitoring mechanism, the bottom layer of the kernel state captures physical signal anomalies through hardware interrupts, and detects bus signal quality, physical layer transmission errors and physical connection status in real time through the clock management unit and hardware register access of the Linux kernel subsystem, and generates a first-level abnormal event; the middle layer of the kernel state detects interrupt storms through the driver level, registers interrupt processing functions in the kernel driver, counts the interrupt trigger frequency of the hardware interface, monitors the sensor chip temperature and power supply voltage anomalies, and generates a second-level abnormal event; the highest layer of the user state ensures the stability of the communication link through the heartbeat packet mechanism and dynamic bandwidth adjustment, sets a dynamic timeout response time, counts the data packet loss rate and bandwidth congestion status within a period of time, and generates a third-level abnormal event.

[0058] Step S1.3, write the first-level abnormal event, the second-level abnormal event and the third-level abnormal event into the message queue, obtain a multi-level abnormal event message queue and notify the main thread.

[0059] Step S2: The main thread dynamically adjusts the working strategy of the worker thread based on the abnormal event. The worker thread collects data and stores it in the ring buffer, then notifies the main thread and synchronization thread. The main thread reads data from the ring buffer regularly to determine the ice condition stage and dynamically adjusts the working strategy of the worker thread. Figure 3 shown. Specifically:

[0060] Step S2.1: The main thread receives the multi-level abnormal event message queue and determines the abnormal level of the sensor.

[0061] Step S2.2: The main thread creates an abnormal event table, records the device ID, abnormal level, and specific description of the abnormal event, and stores the abnormal event table in the data storage module.

[0062] In step S2.3, for a level 1 abnormal event, the main thread immediately stops collecting data from the corresponding sensor in the working thread and triggers a hardware reset or switches to a backup communication interface; for a level 2 abnormal event, the main thread dynamically reduces the data collection frequency of the corresponding sensor in the working thread to reduce data traffic; for a level 3 abnormal event, the main thread only allows the working thread to discard the abnormal data segment of the corresponding sensor.

[0063] In step S2.4, the worker thread establishes a ring buffer. Mutexes and conditional variables are used to secure multi-source sensor data when reading and writing it. Specifically, the worker thread collects data, adds a timestamp to the raw data, and then writes the timestamped raw data into the ring buffer. Before writing the raw data, the worker thread acquires a mutex lock, releases the mutex lock after writing the raw data, and triggers a conditional variable to notify the main thread and synchronization thread. Conditional variables are a key mechanism for inter-thread synchronization in Linux. Used in conjunction with mutexes, they primarily address inter-thread waiting and notification issues.

[0064] In step S2.5, after receiving the condition variable, the main thread acquires the mutex lock regularly, reads the ice thickness data from the ring buffer, and releases the mutex lock.

[0065] In step S2.6, the main thread determines the ice condition stage based on the ice thickness data using the following formula:

[0066]

[0067] in, Indicates the number of days of data observation set. Indicates the minimum consecutive days threshold for trend determination. Indicates the date index when traversing historical data. Indicates the current date index, Indicates the fixed measurement time every day, Indicates the sky The ice thickness measurement at the time, Indicates the sky The ice thickness measurement at the time, represents the daily growth threshold of ice thickness during the growing period, Indicates the length of the stable sealing period determination window, Indicates the ice thickness fluctuation threshold between consecutive days during the stable closure period, Indicates the daily reduction threshold of ice thickness during the ablation period.

[0068] From this we can see that if there is at least one continuous The ice thickness growth exceeded the threshold every day. , it is determined to be the growth period; if there are at least continuous The absolute value of the ice thickness change on any two consecutive days does not exceed the threshold , it is determined to be a stable closure period; if there are at least continuous The ice thickness reduction exceeded the threshold on each day , it is determined to be the ablation period. =7, =3, =5, =8:00, =1.0, =1.0, =1.0, then in the data observation of 7 consecutive days, if the ice thickness increase at 8:00 every day exceeds the threshold of 1.0 for at least 3 consecutive days, it is determined to be a growing period; if the absolute value of the ice thickness change at 8:00 on any two adjacent days does not exceed 1.0 for at least 5 consecutive days, it is determined to be a stable sealing period; if the ice thickness decrease at 8:00 every day exceeds 1.0 for at least 3 consecutive days, it is determined to be a melting period.

[0069] In step S2.7, the main thread dynamically adjusts the acquisition strategy of each sensor of the working thread according to the ice condition stage determined in step S2.6. During the growth period, the working thread maintains the basic sampling rate of each sensor; during the stable sealing period, the working thread reduces the sampling rate of non-critical sensors; during the ablation period, the working thread increases the sampling rate of critical sensors. Specifically, the non-critical sensors are defined as sensors that collect data that indirectly reflects the state of the ice layer or indirectly drives changes in ice conditions, including image acquisition sensors, wind speed sensors, and water flow rate sensors. The critical sensors are defined as sensors that collect data that directly reflects the state of the ice layer or directly drives changes in ice conditions, including water temperature sensors, ambient temperature sensors, ice thickness sensors, solar radiation sensors, and ice stress sensors.

[0070] Step S3, the synchronization thread synchronizes the multi-source heterogeneous frequency data based on the hardware clock source, such as Figure 4 Specifically:

[0071] In step S3.1, the data synchronization module uses the PPS hardware interrupt signal output by the hardware clock source GPS every second and the UTC time parsed by the GPRMC message as the benchmark, calibrates the internal clocks of the system and each sensor through hardware interrupts, and generates a globally unified microsecond-level timestamp.

[0072] In step S3.2, the synchronization thread obtains the mutex lock after receiving the condition variable sent by the working thread in step S2.4, takes out the raw data of each sensor from the ring buffer according to the microsecond timestamp generated in step S3.1, and then releases the mutex lock.

[0073] In step S3.3, the image acquisition sensor, which has the highest sampling frequency, is used as the reference time axis to perform categorical interpolation on the lower-frequency data collected by other sensors. Linear interpolation is used for spatially uniform and gently varying data such as water temperature, ambient temperature, ice thickness, and solar radiation. Kriging spatial interpolation is used for spatially correlated and abrupt data changes such as wind speed, water velocity, and ice stress.

[0074] In step S3.4, the low-frequency sampling data in step S3.3 is interpolated by type and aligned to the reference time axis to generate multi-source data frames with unified time sequence, and strictly sorted by timestamps, and a synchronization data table is established to record timestamps and multi-source data frames; the synchronization data table is then stored in the data storage module, thereby achieving microsecond-level time synchronization and spatiotemporal consistency of multi-source data in a complex environment.

[0075] In step S4, the local edge layer and the remote center layer collaborate to store data and provide data access and push interfaces. Specifically:

[0076] In step S4.1, the data storage module adopts a collaborative storage architecture between the local edge layer and the remote center layer. The local edge layer uses the SQLite database to build a real-time data cache, while the remote center layer uses TimescaleDB for distributed time series data storage. All uploaded data is managed by time partition (one shard per day). The data stored in the local edge layer and the remote center layer includes the exception event table in the main thread and the synchronization data table in the synchronization thread. Atomic operations are used when storing data to ensure data integrity.

[0077] Step S4.2: When the network is disconnected, the local edge layer resumes transmission to the remote center layer based on the timestamp of the last successful synchronization, and verifies the data integrity frame by frame. If an abnormal frame is found, it will be retransmitted;

[0078] Step S4.3, set up a timed incremental synchronization mechanism, trigger an incremental synchronization task every once in a while, compare the latest synchronization timestamps of the local edge layer and the remote center layer, extract the unsynchronized data blocks to synchronize the data of the local edge layer and the remote center layer; provide data access services through RESTful API and WebSocket interface, RESTful API supports combined query (filtered by timestamp range, device ID, and anomaly level), and WebSocket interface pushes high-frequency data of the ablation period in real time, realizing full-link data management and secure access from real-time caching of the local edge layer to long-term storage of the remote center layer.

[0079] Those skilled in the art will appreciate that the above-described embodiments merely represent several embodiments of the present invention, and their descriptions are relatively specific and detailed, but should not be construed as limiting the scope of the present invention. It should be noted that a person of ordinary skill in the art may make various modifications and improvements without departing from the scope of the present invention, and these modifications and improvements fall within the scope of protection of the present invention. Therefore, the scope of protection of the present invention shall be subject to the appended claims.

Claims

1. A multi-sensor hierarchical monitoring and data synchronization processing system based on Linux, characterized in that: The multi-sensor hierarchical monitoring and data synchronization processing system includes a multi-source data interface monitoring module, a data acquisition module, a data synchronization module and a data storage module; specifically: The multi-source data interface monitoring module is used to monitor the physical signals, hardware interfaces and communication link status of multi-source sensors in real time, and ensure the reliability and integrity of multi-source sensor data through a three-level hierarchical monitoring mechanism; The data acquisition module is used to dynamically collect multi-source sensor data, adjust the data acquisition frequency according to the abnormal level and ice condition stage, and work together through the main thread and the working threads of each sensor to ensure the efficiency and real-time performance of data acquisition; The data synchronization module is used to achieve accurate synchronization of multi-source heterogeneous frequency data. Based on the hardware clock source and the type-based interpolation algorithm, the data with different sampling rates are aligned to a unified time axis through the synchronization thread to ensure the time consistency of the data. The data storage module is used to provide a collaborative storage architecture between the local edge layer and the remote center layer. The local edge layer uses the SQLite database to cache real-time data, and the remote center layer uses TimescaleDB to implement distributed storage. It also provides data access services through the RESTful API and WebSocket interface to achieve low-latency caching and highly reliable persistent storage of data.

2. The Linux-based multi-sensor hierarchical monitoring and data synchronization processing system according to claim 1, characterized in that: The multi-source data interface monitoring module covers all-round monitoring of multi-source sensors from the physical signal layer, hardware interface layer to the communication link layer through a three-level hierarchical monitoring mechanism. The three-level hierarchical monitoring mechanism is implemented through the Linux kernel state bottom layer, kernel state middle layer, and user state top layer. The multi-source sensors include image acquisition sensors, water temperature sensors, ambient temperature sensors, ice thickness sensors, solar radiation sensors, wind speed sensors, water flow rate sensors, and ice layer stress sensors.

3. The Linux-based multi-sensor hierarchical monitoring and data synchronization processing system according to claim 1, characterized in that: The data acquisition module adopts a collaborative architecture of main threads and working threads, and realizes efficient acquisition and abnormal response of multi-source sensor data through dynamic thread scheduling and adaptive acquisition strategy. The multi-source sensor data includes: image data, water temperature data, ambient temperature data, ice thickness data, solar radiation data, wind speed data, water flow rate data, and ice layer stress data.

4. The Linux-based multi-sensor hierarchical monitoring and data synchronization processing system according to claim 1, characterized in that: The hardware clock source used by the data synchronization module is the GPS module, and the PPS hardware interrupt signal output by the GPS module every second and the UTC time parsed from the GPRMC message are used as the time reference.

5. A Linux-based multi-sensor hierarchical monitoring and data synchronization processing method, characterized in that: The multi-sensor hierarchical monitoring and data synchronization processing system according to any one of claims 1 to 4 is implemented, comprising the following steps: Step S1: Initialize the system hardware and monitor the status of multiple sensors through a three-level hierarchical monitoring mechanism to capture abnormal events in real time. Step S2: The main thread dynamically adjusts the working strategy of the worker thread based on the abnormal event. The worker thread collects data and stores it in the ring buffer, notifying the main thread and synchronization thread. The main thread periodically reads data from the ring buffer to determine the ice condition stage and dynamically adjusts the working strategy of the worker thread. Step S3, the synchronization thread synchronizes the multi-source heterogeneous frequency data based on the hardware clock source; In step S4, the local edge layer and the remote center layer collaborate to store data and provide data access and push interfaces.

6. The Linux-based multi-sensor hierarchical monitoring and data synchronization processing method according to claim 5, characterized in that: The step S1 is specifically as follows: Step S1.1: The system loads the Linux kernel and allocates independent working threads and memory resources for the multi-source sensors, and initializes the multi-source data interface monitoring module; Step S1.2: Monitor the status of multiple sensors through a three-level hierarchical monitoring mechanism. The kernel state captures physical signal anomalies through hardware interrupts at the lowest level. Through the clock management unit and hardware register access of the Linux kernel subsystem, bus signal quality, physical layer transmission errors, and physical connection status are detected in real time to generate a level 1 abnormal event. The kernel-mode middle layer detects interrupt storms at the driver level, registers interrupt handling functions in the kernel driver, counts interrupt trigger frequencies of hardware interfaces, monitors sensor chip temperature and power supply voltage anomalies, and generates level-two abnormal events. The user-mode top layer ensures communication link stability through a heartbeat packet mechanism and dynamic bandwidth adjustment, sets a dynamic timeout response time, counts packet loss rates and bandwidth congestion status over a period of time, and generates level-three abnormal events. Step S1.3, write the first-level abnormal event, the second-level abnormal event and the third-level abnormal event into the message queue, obtain a multi-level abnormal event message queue and notify the main thread.

7. The Linux-based multi-sensor hierarchical monitoring and data synchronization processing method according to claim 6, characterized in that: The step S2 is specifically as follows: Step S2.1: The main thread receives the multi-level abnormal event message queue and determines the abnormal level of the sensor; Step S2.2: The main thread creates an abnormal event table, records the device ID, abnormal level, and specific description of the abnormal event, and stores the abnormal event table in the data storage module; Step S2.3: For a level 1 abnormal event, the main thread immediately stops collecting data from the corresponding sensor in the worker thread and triggers a hardware reset or switches to a backup communication interface. For a level 2 abnormal event, the main thread dynamically reduces the data collection frequency of the corresponding sensor in the worker thread to reduce data traffic. For a level 3 abnormal event, the main thread only causes the worker thread to discard the abnormal data segment of the corresponding sensor. Step S2.4: The working thread establishes a ring buffer. When reading and writing multi-source sensor data, the ring buffer uses mutex locks and condition variables to ensure the security of multi-source sensor data. Step S2.5: After receiving the condition variable, the main thread periodically acquires the mutex lock, reads the ice thickness data from the ring buffer, and releases the mutex lock; In step S2.6, the main thread determines the ice condition stage based on the ice thickness data using the following formula: ,in, Indicates the number of days of data observation set. Indicates the minimum consecutive days threshold for trend determination. Indicates the date index when traversing historical data. Indicates the current date index, Indicates the fixed measurement time every day, Indicates the sky The ice thickness measurement at the time, Indicates the sky The ice thickness measurement at the time, represents the daily growth threshold of ice thickness during the growing period, Indicates the length of the stable sealing period determination window, Indicates the ice thickness fluctuation threshold between consecutive days during the stable closure period, represents the daily reduction threshold of ice thickness during the ablation period; It follows that if there are at least continuous The ice thickness growth exceeded the threshold every day. , it is determined to be the growth period; if there are at least continuous The absolute value of the ice thickness change on any two consecutive days does not exceed the threshold , it is determined to be a stable closure period; if there are at least continuous The ice thickness reduction exceeded the threshold on each day , it is determined to be the ablation period; In step S2.7, the main thread dynamically adjusts the acquisition strategy of each sensor of the working thread according to the ice condition stage determined in step S2.

6. During the growth period, the working thread maintains the basic sampling rate of each sensor; during the stable sealing period, the working thread reduces the sampling rate of non-critical sensors; during the ablation period, the working thread increases the sampling rate of critical sensors.

8. The Linux-based multi-sensor hierarchical monitoring and data synchronization processing method according to claim 7, characterized in that: In the step S2: Step S2.4 specifically includes: the worker thread collects data and adds a timestamp to the raw data, then writes the timestamped raw data into the ring buffer, acquires a mutex lock before writing the raw data, releases the mutex lock after writing the raw data, and triggers a condition variable to notify the main thread and synchronization thread; the condition variable is an important mechanism for inter-thread synchronization in Linux and is used in conjunction with the mutex lock; The specific steps of step S2.7 are as follows: the non-critical sensors are defined as sensors that collect data that indirectly reflects the state of the ice layer or indirectly drives changes in ice conditions, including image acquisition sensors, wind speed sensors, and water flow rate sensors; the critical sensors are defined as sensors that collect data that directly reflects the state of the ice layer or directly drives changes in ice conditions, including water temperature sensors, ambient temperature sensors, ice thickness sensors, solar radiation sensors, and ice layer stress sensors.

9. The Linux-based multi-sensor hierarchical monitoring and data synchronization processing method according to claim 7, characterized in that: The step S3 is specifically as follows: Step S3.1: The data synchronization module uses the PPS hardware interrupt signal output by the hardware clock source GPS every second and the UTC time parsed by the GPRMC message as the benchmark, calibrates the internal clocks of the system and each sensor through hardware interrupts, and generates a globally unified microsecond-level timestamp; Step S3.2: The synchronization thread acquires the mutex lock after receiving the condition variable sent by the worker thread in step S2.4, extracts the raw data of each sensor from the ring buffer according to the microsecond timestamp generated in step S3.1, and then releases the mutex lock; Step S3.3: Using the image acquisition sensor, which has the highest data sampling frequency, as the reference time axis, perform categorical interpolation on the low-frequency sampling data collected by other sensors. Linear interpolation is used for spatially uniform and gently varying data such as water temperature, ambient temperature, ice thickness, and solar radiation data. Kriging spatial interpolation is used for spatially correlated and abrupt data such as wind speed, water velocity, and ice stress data. Step S3.4: Perform categorical interpolation on the low-frequency sampling data in step S3.3 and align them to the reference time axis to generate multi-source data frames with a unified time sequence. These frames are strictly sorted by timestamps, and a synchronization data table is established to record the timestamps and multi-source data frames. The synchronized data table is then stored in the data storage module.

10. The Linux-based multi-sensor hierarchical monitoring and data synchronization processing method according to claim 9, characterized in that: The step S4 is specifically as follows: In step S4.1, the data storage module adopts a collaborative storage architecture between the local edge layer and the remote center layer. The local edge layer uses the SQLite database to build a real-time data cache, and the remote center layer implements distributed time series data storage based on TimescaleDB. All data uploaded by the system is stored by time partition. The data stored in the local edge layer and the remote center layer includes the exception event table in the main thread and the synchronization data table in the synchronization thread, and atomic operations are used when storing data. Step S4.2: When the network is disconnected, the local edge layer resumes transmission to the remote center layer based on the timestamp of the last successful synchronization, and verifies the data integrity frame by frame. If an abnormal frame is found, it will be retransmitted; Step S4.3, set up a timed incremental synchronization mechanism, trigger an incremental synchronization task every once in a while, compare the latest synchronization timestamps of the local edge layer and the remote center layer, extract the unsynchronized data blocks to synchronize the local edge layer and remote center layer data; provide data access services to achieve full-link data management and secure access from real-time caching at the local edge layer to long-term storage at the remote center layer.

Images