Edge computing multi-protocol adaptive hot plug sensor gateway and control method

Abstract

This invention relates to the fields of Internet of Things (IoT) and edge computing technology, and discloses an edge computing multi-protocol adaptive hot-swappable sensor gateway and control method. This method establishes a module configuration table through GPIO dual-edge debouncing detection and UART enumeration handshake, activating a scenario-specific adaptive acquisition strategy; it employs adaptive high-speed baseline modeling and a double-buffered pre-trigger mechanism to complete high-frequency edge preprocessing; it implements fault isolation through a dual-criteria circuit breaker strategy based on heartbeat timeout and CRC error rate; it uses UART latency compensation clock calibration and hierarchical offline caching for breakpoint resumption to ensure data timing integrity; and finally, it achieves full-system firmware online iteration through multi-link redundant switching and two-level cascaded OTA. This invention enables plug-and-play access of multi-protocol sensors, complete retention of precursor data of impact events, and long-term stable system operation in unattended, harsh outdoor environments.

Description

Technical Field

[0001] This invention relates to the fields of Internet of Things and edge computing technology, and more specifically, to an edge computing multi-protocol adaptive hot-swappable sensor gateway and control method. Background Technology

[0002] With the rapid development of the Industrial Internet of Things (IIoT) and field disaster monitoring systems, field monitoring nodes often need to simultaneously connect to various heterogeneous sensors such as temperature, humidity, vibration, and tension sensors, and the sensor types frequently change with business needs. The interface types of existing sensor gateways are fixed in the PCB design at the factory. If new types of sensors need to be connected after field deployment, the entire device often needs to be replaced, resulting in high time and equipment costs. At the same time, traditional gateways use a single master controller to handle all peripheral I / O access. The intensive acquisition of high-frequency vibration data can severely consume system bus bandwidth, leading to CPU thread blocking and network communication delays.

[0003] Regarding data reliability, field nodes rely on operator network communication, and network fluctuations are unavoidable. Existing gateways have limited cache space, and network outages can easily lead to the permanent loss of critical historical event data. Even if the data is recovered and uploaded, the lack of a multi-level clock synchronization mechanism results in relative offsets in the timelines of data from different sensors, rendering the backend time-series early warning system ineffective in cross-sensor correlation analysis.

[0004] Regarding system reliability, incidents such as lightning strikes, electrostatic interference, and water ingress short circuits frequently occur in industrial and natural environments. Existing equipment typically shares the same power rail on the motherboard for all external sensor interfaces. If a sensor short-circuits, it instantly lowers the voltage of the entire gateway's power rail, causing the entire system to crash. Furthermore, the lack of plug-and-play functionality and automatic fault location and disconnection mechanisms makes on-site troubleshooting and recovery extremely difficult, particularly in unattended field locations. Summary of the Invention

[0005] This invention provides an edge computing multi-protocol adaptive hot-swappable sensor gateway and control method, which solves the technical problems of data loss of critical events during sensor network outages, cross-sensor clock skew, and system-wide downtime caused by single-path failures in related technologies.

[0006] This invention provides a control method for an edge computing multi-protocol adaptive hot-swappable sensor gateway, comprising the following steps: S1, acquire the physical slot level transition signal, use GPIO dual-edge debouncing detection and UART enumeration handshake protocol to establish a module type configuration table carrying hardware type identifier and serial number; S2, activates the scene-specific adaptive acquisition strategy according to the module type configuration table, uses adaptive high-speed baseline modeling and double-buffered pre-trigger retention mechanism to complete high-frequency edge preprocessing, and outputs standardized heartbeat frames for each channel; S3 receives heartbeat frames and UART communication data from each channel, adopts a hardware and software combined circuit breaker strategy with heartbeat timeout and CRC error rate as dual criteria, and outputs an updated type configuration table and fault alarm message. S4 aggregates standardized heartbeat frames and fault alarm messages from various channels, adopts UART delay compensation clock calibration and hierarchical offline caching breakpoint resume method, outputs a time-continuous cloud data sequence and maintains cloud MQTT connection; S5, relying on cloud-based MQTT connections and module type configuration tables, adopts multi-link redundancy switching and a two-level cascaded OTA packet verification and rollback mechanism to output a full system firmware upgrade result report.

[0007] Furthermore, in S1, after the GPIO interrupt controller of the baseboard senses the rising edge transition, the hot-plug daemon performs a debouncing judgment. If the time interval between the previous rising edge event in the same slot is less than the preset debouncing time window, the current event is ignored; otherwise, an enumeration frame is sent to the UART port bound to the slot. After the master controller sends an enumeration frame, it starts a response waiting timer. If no response frame is received within the preset timeout period, the enumeration frame is resent. If no response is received after the number of resentments reaches the preset limit, the slot is recorded as an enumeration failure in the module type configuration table. After parsing the response frame, the main controller dynamically instantiates the corresponding acquisition task object and protocol parser based on the hardware type identifier code, and writes the slot number, serial number, hardware type identifier code and current status flag into the module type configuration table; when the module is physically unplugged, the GPIO detection pin senses the falling edge transition, the daemon process suspends the acquisition task thread and destroys the protocol parser instance, and updates the status flag of the corresponding record in the module type configuration table to "unregistered".

[0008] Furthermore, in S2, the submodule MCU extracts a three-dimensional feature vector from the sampled data within each fixed-length analysis window. The three components of the three-dimensional feature vector are, in order: the root mean square of the three-axis resultant acceleration amplitude, the zero-crossing rate of the three-axis resultant acceleration sequence, and the approximate centroid value of the time-domain segmented bandpass energy weighted spectrum. The method for calculating the approximate value of the spectral centroid is as follows: the sampled sequence is passed through three sets of IIR bandpass filters to extract the filtered output sequences of the low-frequency band, mid-frequency band and high-frequency band respectively. The energy value of the frequency band is obtained by summing the square values ​​of each sampling point of each set of filtered output sequences. The approximate value of the spectral centroid is obtained by dividing the weighted sum of the center frequency of each frequency band and the corresponding energy value by the sum of the energy values ​​of the three frequency bands.

[0009] Furthermore, in S2, after the submodule is powered on, it enters a silent initialization period, during which the three-dimensional feature vector is continuously extracted and stored in the initialization sample buffer. After the silent initialization period ends, the median of each feature component is calculated as the initial mean vector, and the median of the absolute deviation of each feature component is calculated and its square is used as the corresponding component of the initial diagonal covariance vector. The baseline model consists of a mean vector and a diagonal covariance vector. When the root mean square magnitude component of the three-dimensional feature vector is lower than a first threshold, it is determined to be a quiet period, and the mean vector and diagonal covariance vector are updated in an exponential smoothing manner. When the root mean square magnitude component exceeds the first threshold, the baseline model parameters are frozen and updates are stopped.

[0010] Further, in S2, the Mahalanobis distance is calculated based on the three-dimensional feature vector and the baseline model in the current analysis window. The Mahalanobis distance is a scalar value obtained by summing the square of the difference between each feature component and the corresponding mean vector component, dividing by the corresponding diagonal covariance vector component, and then taking the square root. When the Mahalanobis distance exceeds the second threshold, it is marked as an abnormal frame candidate; when the Mahalanobis distance of a preset number of consecutive analysis windows exceeds the second threshold, the submodule enters the event capture mode.

[0011] Furthermore, in S2, the submodule maintains a double buffer structure, one of which is a rolling history buffer, which uses a ring buffer structure to continuously store the original sampled data; the other is an event capture buffer, which is activated when entering the event capture mode. When the event capture mode is triggered, the submodule atomically freezes the write pointer of the rolling history buffer, copies the precursor data in it to the event capture buffer as the precursor segment, and then appends the newly sampled data as the main impulse segment; when the Mahalanobis distance drops back below the third threshold and maintains a continuous quiet window, it exits the event capture mode and reports the complete event data packet containing the precursor segment, the main impulse segment and the decay segment to the master controller via UART.

[0012] Furthermore, in S3, for the submodule in the active reporting mode, the main controller updates the heartbeat timestamp of the corresponding channel when it receives a heartbeat frame that has passed CRC verification; for the submodule in the passive response mode, the main controller updates the heartbeat timestamp of the channel when it receives a valid response frame after sending a query frame. The master controller's heartbeat monitoring thread polls each channel at fixed intervals: if the time difference between the last heartbeat timestamp and the current time of a certain channel exceeds the fourth threshold, the heartbeat is judged to have timed out; if the ratio of the CRC check failure count to the total number of received frames exceeds the fifth threshold, the communication quality is judged to have degraded; once any condition is met, the fault isolation process is triggered. At the software level, the status of the record in the module type configuration table is updated to fault isolation, and at the hardware level, the master controller drives the MOSFET power control switch to cut off the power supply to the slot.

[0013] Furthermore, in S4, after the main controller corrects its own system clock through the SNTP protocol, it starts the periodic clock calibration process for each sub-module: the main controller records the start time of sending the calibration frame and calculates the UART one-way transmission delay. When the UART receive interrupt is triggered, the sub-module reads the local timer count value and sends it back. Based on this, the main controller calculates the clock deviation compensation amount and sends it to the sub-module to correct its local clock bias. When both network links are interrupted, the system switches to offline caching mode: the first level is for sub-modules to write data frames into local circular buffers, and event data packets are preserved first; the second level is for the master controller to write backlogged data into external large-capacity storage in time slices, with each record appended with the sub-module's local timestamp and the master controller's global timestamp; after the network is restored, the data is resumed to the cloud in time order.

[0014] Furthermore, in S5, the master controller simultaneously establishes an Ethernet MQTT session and a 4G MQTT session, prioritizes publishing data through the Ethernet session, switches to the 4G MQTT session when the Ethernet session is disconnected, and automatically switches back after the Ethernet session is restored. The first level of the two-level cascaded OTA is directed towards the main controller itself. The main controller writes the firmware to the backup system partition and performs integrity verification. After passing the verification, it switches the active partition identifier and restarts. If the new firmware does not send a running confirmation signal within a preset time, it automatically reverts to the old partition. The second level is directed towards the sub-module. The main controller divides the firmware into sequentially numbered data packets and sends them to the sub-module Bootloader via UART. Each packet is written to the target Flash sector after being checked by CRC32. After all data packets are received, an overall verification is performed. If the verification passes, the boot partition is switched and reset. If the verification fails, it reverts to the original firmware partition.

[0015] Furthermore, an edge computing multi-protocol adaptive hot-swappable sensor gateway, used to execute the steps in the above-described edge computing multi-protocol adaptive hot-swappable sensor gateway control method, includes: The hot-swap enumeration module is used to collect physical slot level transition signals. It adopts GPIO dual-edge debouncing detection and UART enumeration handshake protocol to establish a module type configuration table carrying hardware type identifier and serial number. The scene-specific acquisition and edge preprocessing module is used to activate the scene-specific adaptive acquisition strategy according to the module type configuration table. It adopts adaptive high-speed baseline modeling and double-buffered pre-trigger retention mechanism to complete high-frequency edge preprocessing and outputs standardized data frames for each channel. The heartbeat monitoring and fault isolation module is used to receive heartbeat frames and UART communication data from each channel. It adopts a hardware and software combined circuit breaker strategy with heartbeat timeout and CRC error rate as dual criteria, and outputs an updated type configuration table and fault alarm messages. The data transmission and clock calibration module is used to aggregate standardized data frames and fault alarm messages from various channels. It adopts UART delay compensation clock calibration and hierarchical offline caching breakpoint resume method to output a time-continuous cloud data sequence and maintain the cloud MQTT connection. The communication switching and OTA upgrade module is used to output a full system firmware upgrade result report by relying on the cloud MQTT connection and module type configuration table, adopting multi-link redundancy switching and a two-level cascaded OTA packet verification and rollback mechanism.

[0016] The beneficial effects of this invention are as follows: The sensor submodules are plug-and-play identified by using GPIO dual-edge debouncing detection and UART enumeration handshake protocol. The main controller dynamically instantiates the acquisition task object and protocol parser based on the hardware type identifier code, and can complete the access and deregistration of any type of submodule without stopping the system or modifying the static configuration code. For the high-frequency vibration channel, an adaptive high-speed baseline modeling and a double-buffered pre-trigger retention mechanism are used to move the data processing task to the submodule MCU. The main controller only receives the preprocessing results, which fundamentally eliminates the blocking of the main control thread by high-frequency acquisition, and at the same time realizes the complete retention of the precursor data of the impact event. By employing a combined hardware and software circuit breaker strategy based on both heartbeat timeout and CRC error rate criteria, software thread suspension and hardware slot power-off are simultaneously executed when a channel anomaly is detected. This isolates the electrical impact of the fault within an independent power domain, preventing a single-channel fault from spreading to other channels. Furthermore, by using UART latency compensation clock calibration and a tiered offline caching breakpoint resumption method, the timestamps of each submodule are continuously aligned with the main control global clock. During network outages, a dual timestamp mechanism is used to preserve the integrity of the data sequence, and data is retransmitted in an orderly manner after the network is restored, ensuring the continuity of the cloud data sequence timeline. Attached Figure Description

[0017] Figure 1 This is a flowchart of an edge computing multi-protocol adaptive hot-swappable sensor gateway control method according to the present invention; Figure 2 This is a flowchart of a multi-protocol adaptive hot-swappable sensor gateway control method for edge computing according to the present invention. Figure 1 ; Figure 3 This is a flowchart of a multi-protocol adaptive hot-swappable sensor gateway control method for edge computing according to the present invention. Figure 2 . Detailed Implementation

[0018] The subject matter described herein will now be discussed with reference to exemplary embodiments. It should be understood that these embodiments are discussed only to enable those skilled in the art to better understand and implement the subject matter described herein, and changes may be made to the function and arrangement of the elements discussed without departing from the scope of this specification. Various processes or components may be omitted, substituted, or added as needed in the examples. Furthermore, some features described in the examples may be combined in other examples.

[0019] At least one embodiment of the present invention discloses an edge computing multi-protocol adaptive hot-plug sensor gateway control method, such as... Figures 1 to 3 As shown, it includes the following steps: S1, acquire the physical slot level transition signal, use GPIO dual-edge debouncing detection and UART enumeration handshake protocol to establish a module type configuration table carrying hardware type identifier and serial number; The gateway baseboard of this invention has four physical slots, each equipped with an independent GPIO status detection pin. In the default empty slot state, this pin is kept low by an internal pull-down circuit on the baseboard. Its level directly reflects the physical occupancy of the corresponding slot, without relying on any software polling, ensuring real-time detection. When a sensor submodule is physically inserted into a slot, the submodule's connector has a dedicated pull-up pin, which, after reliably connecting to the GPIO detection pin of the baseboard slot, pulls its level from low to high. After the baseboard's GPIO interrupt controller detects a rising edge transition, the hot-plug daemon performs a debouncing judgment on the rising edge event: if the time interval between the previous rising edge event in the same slot is less than the debouncing time window (the default value of the debouncing time window is 1000 milliseconds), it is determined to be a repeated trigger caused by connector jitter, and this event is ignored; if the time interval exceeds the debouncing time window, it is determined to be a valid insertion event, and the daemon sends a standard enumeration frame to the UART port bound to that slot. The enumeration frame has a fixed frame header identifier field, command code field, and frame tail CRC8 check field, used to initiate the identity verification handshake process with the submodule.

[0020] After completing power-on initialization and peripheral self-test, the STM32 MCU of the submodule enters a listening state waiting for the enumeration frame. The UART receive interrupt is activated, and it waits for the frame header identifier from the master controller. After the master controller sends the enumeration frame, it starts an acknowledgment waiting timer. The default value for the timeout period is 500 milliseconds, which covers the maximum time from power-on to completion of initialization and activation of the UART interrupt by the submodule MCU. If an acknowledgment frame is received from the submodule within the timeout period, the subsequent parsing process continues. If no acknowledgment is received within the timeout period, the master controller retransmits the enumeration frame. The default maximum number of retransmissions is 3. If no acknowledgment is received after 3 retransmissions, the master controller records the slot as an enumeration failure in the type configuration table, does not activate any acquisition tasks, but continues to monitor the GPIO pin of the slot so that the enumeration process can be retried by the next valid rising edge event after the connector stabilizes again.

[0021] After receiving the enumeration frame and completing frame format verification and CRC8 check, the submodule constructs a response frame and returns it to the main control board via UART. The response frame carries two core fields: a unique serial number (generated from the device identifier code written to the MCU OTP area during production using a deterministic hash algorithm to ensure global uniqueness) and a hardware type identifier. The hardware type identifier covers three definitions: ordinary RS485 acquisition module (low frequency, second-level heartbeat pull), high-frequency RS485 vibration acquisition module (kilohertz-level sampling, autonomous edge preprocessing followed by active reporting), and high-precision analog acquisition module (24-bit ADC signal chain, calibrated followed by active reporting). The main control board can determine all protocol elements of the module, such as data format, transmission direction, acquisition cycle, and protocol parsing rules, by parsing the hardware type identifier, without needing to query any external configuration files.

[0022] After successfully parsing the response frame, the main controller dynamically instantiates the corresponding acquisition task object in system memory based on the hardware type identifier (using a factory pattern, with one predefined acquisition task class for each hardware type). Simultaneously, it instantiates the corresponding protocol parser (responsible for parsing the UART frame format of that type of module into a unified channel data structure). The instance handle, along with the module's slot number, serial number, hardware type identifier, registration timestamp, and current status flag, is written to a new record in the module type configuration table. The initial value of the status flag is "normal operation." The type configuration table is maintained in the main controller's memory as a linked list, supporting dynamic addition and deletion at runtime. It serves as the global state foundation for all subsequent steps—S2 reads it to determine the acquisition strategy for each channel, S3 reads and writes it to mark fault isolation status, and S5 reads it to identify the target module for OTA commands.

[0023] When a registered module is physically unplugged, the connector disconnects, causing the GPIO detection pin level to change from high to low. The baseboard GPIO interrupt controller detects the falling edge transition, and the daemon process immediately suspends the acquisition task thread corresponding to that slot. After the thread safely exits, it destroys the bound protocol parser instance, closes the corresponding UART port, releases all occupied memory resources, and finally updates the status flag of the corresponding record in the type configuration table to "unregistered." The entire unregistration process is completed within microseconds to milliseconds after the interrupt context is triggered. The main control program does not need to know the module type in advance, does not need to stop and restart, and does not need to modify any static configuration code. This achieves plug-and-play identification and unregistration of any type of submodule under the condition that the main control program has no preset constraints on the sensor type. The final output of step S1 is a type configuration table containing complete description information of all currently online modules. This table is continuously maintained and updated throughout the entire system operation cycle and is the direct and sole basis for the execution of the S2 scenario-based strategy.

[0024] S2, activates the scene-specific adaptive acquisition strategy according to the module type configuration table, uses adaptive high-speed baseline modeling and double-buffered pre-trigger retention mechanism to complete high-frequency edge preprocessing, and outputs standardized heartbeat frames for each channel; Based on the module type configuration table output by S1, the master controller activates the corresponding acquisition strategy for each record in normal operation. Modules with different hardware type identifiers execute completely different data acquisition and processing flows. The processing results of each channel are ultimately encapsulated into standardized channel data frames (the frame structure includes slot number, data type flag, data content payload, and reception timestamp) for use by S3 parallel monitoring and S4 unified management. The three module types differ in their heartbeat survival determination: the high-frequency RS485 vibration acquisition module and the high-precision analog quantity acquisition module both operate in active reporting mode. The independent heartbeat timer in the submodule firmware sends heartbeat frames to the master controller at fixed intervals. The master controller considers the channel alive if it receives any valid heartbeat frame. The ordinary RS485 acquisition module operates in passive response mode. If the master controller receives a valid response frame within a specified time after each query frame, it considers the channel's heartbeat valid. If there is no response after several consecutive queries, the fault isolation process of S3 is triggered. Both determination methods are managed uniformly in S3 using a heartbeat timestamp update mechanism, which is transparent to the upper-layer logic.

[0025] For channels identified as ordinary RS485 acquisition modules in the type configuration table, the master controller periodically sends query frames to the sub-modules according to a preset heartbeat frequency. Upon receiving the query frame, the sub-module returns the currently cached sensor measurement values ​​in the form of a response frame. The master controller parses the numerical fields in the response frame, appends a receive timestamp, and encapsulates it into a low-frequency current value type channel data frame. Simultaneously, it updates the channel's heartbeat timestamp to the current moment. Because the data changes slowly in ordinary RS485 modules, this pull strategy can keep the master controller's UART bandwidth usage at a very low level, reserving sufficient communication resources for other channels.

[0026] For channels identified as high-precision analog signal acquisition modules in the type configuration table, the sub-module internally consists of a low-power, high-precision STM32F405 paired with a 4-channel 24-bit ADC chip, forming an independent signal chain. This chain independently performs high-precision sampling, gain correction, and zero-bias correction calculations for the four analog inputs. The final calibrated digital engineering values ​​are then actively reported to the main controller via UART at fixed intervals. The main controller only needs to add a timestamp to the received values ​​and encapsulate them into channel data frames of high-precision calibration value type. Because the analog-to-digital conversion process is physically isolated from the main control board's RF circuitry (4G, Wi-Fi), electromagnetic interference from the main control side cannot couple to the analog signal acquisition link of this module, ensuring signal acquisition accuracy.

[0027] For channels identified as high-frequency RS485 vibration acquisition modules in the type configuration table, since their original sampling rate is on the order of kilohertz, directly transmitting the raw data stream to the main controller would saturate the UART link bandwidth and cause the main controller thread to be blocked for a long time. Therefore, this step forwards the data processing task to the sub-module MCU, and the main controller is only responsible for receiving the result data or complete event packets after edge preprocessing. The core mechanism of this edge preprocessing process includes two tightly coupled parts: adaptive Gaussian baseline modeling and double-buffered pre-trigger retention. This is the core of the present invention in solving the two key technical problems of fixed threshold failure and precursor data loss in the prior art. The specific implementation is as follows.

[0028] Feature extraction: The MCU submodule continuously samples the raw triaxial acceleration data from the MEMS accelerometer at a fixed sampling rate, extracting a three-dimensional feature vector from the sample data within each fixed-length analysis window. The default analysis window length is 256 sampling points, corresponding to a time span of approximately 128 milliseconds at a 2kHz sampling rate. This parameter can be remotely adjusted by the main controller via a UART configuration frame. The three components of the feature vector are as follows: the first component is the root mean square of the triaxial sum acceleration amplitude of all sampling points within the current window, reflecting the overall energy level of the signal; the second component is the zero-crossing rate of the triaxial sum acceleration sequence within the current window crossing its window mean baseline, i.e., the number of times the signal crosses the mean baseline per unit time, reflecting the frequency components of the signal; the third component is the approximate centroid value of the time-domain segmented bandpass energy weighted spectrum, the calculation process of which is as follows.

[0029] The submodule sequentially passes the sampled sequence of the current analysis window through three pre-installed IIR bandpass filters to extract filtered output sequences for the low-frequency band (default cutoff frequency range is 5Hz to 100Hz), mid-frequency band (default cutoff frequency range is 100Hz to 500Hz), and high-frequency band (default cutoff frequency range is 500Hz to 1000Hz). The sum of the squares of all sampled points in each filtered output sequence yields the energy value of that frequency band within the current window. The energy values ​​of the three frequency bands are denoted as follows: , , The center frequencies of the three frequency bands are respectively , , Then the approximate value of the spectral centroid The calculation method is as follows:

[0030] in The default value is 52.5Hz. The default value is 300Hz. The default value is 750Hz, which are the arithmetic center frequencies of the corresponding frequency bands; , , These represent the sum of squares of the sampled points of the time-domain filtered output sequence within the current analysis window for the low-frequency, mid-frequency, and high-frequency bands, respectively; when the sum of the energies of the three frequency bands is zero... The value is zero. The coefficients of the above three sets of IIR filters are pre-calculated and fixed according to the sampling rate and frequency band boundaries during the compilation of the submodule firmware. During runtime, only multiplication and addition operations are performed. All filtering and spectral centroid calculations for a single analysis window can be completed in about 2 milliseconds on the floating-point unit of the STM32F4 series MCU, meeting the requirements for real-time processing. The three frequency band boundary parameters can be remotely adjusted by the main controller via UART configuration frames to adapt to the differences in background vibration frequency characteristics under different installation scenarios.

[0031] Baseline initialization and adaptive update: After power-on, the submodule first enters a silent initialization period, with a default duration of 300 seconds. During this period, the submodule's heartbeat timer operates normally, sending heartbeat frames to the main controller at fixed intervals, and the S3 heartbeat monitoring mechanism functions normally for this channel. Simultaneously, the submodule continuously collects data and extracts feature vectors, but does not perform any event detection. It only stores the feature vectors of each analysis window in chronological order into the initialization sample buffer, waiting for the silent period to end for baseline initialization calculation. After the silent initialization period ends, the submodule calculates the median for each feature component of all samples in the buffer, combining the medians of the three components into an initial mean vector; for each feature component, it calculates the median of the absolute value of the difference between each sample and the corresponding median (i.e., the median absolute deviation, MAD), and uses the square of each component's MAD as the corresponding component of the initial diagonal covariance vector. Using the median instead of the mean for initialization is to suppress the contamination of the initial baseline value by installation operation noise or occasional disturbances that may exist during the silent period, so that the initial baseline model can accurately reflect the real background vibration level during the first deployment without manual calibration.

[0032] The baseline model consists of a mean vector. and diagonal covariance vector It consists of two parts, each containing three floating-point components, requiring a total of 6 floating-point units for model storage to accommodate the limited SRAM capacity of the submodule MCU. After the silent initialization period, the baseline model switches to an exponential smoothing update mechanism triggered by the quiet period condition: when the first component (root mean square magnitude) of the current analysis window feature vector is lower than the first threshold, the current state is determined to be the quiet period, and the mean vector is updated accordingly. The update method for each component is as follows:

[0033] The diagonal covariance vector of the first The update method for each component is as follows:

[0034] in and The first The values ​​of each mean component before and after the update; and The first The values ​​of the diagonal covariance components before and after the update; The th feature vector of the current analysis window One component; To preserve the coefficient, its default value is 0.995, giving the baseline long-term memory characteristics so that it does not fluctuate drastically due to short periods of quiet; This refers to the update step size, with a default value of 0.005, allowing the baseline to slowly track the long-term drift of the real background vibration. When the root mean square amplitude exceeds the first threshold, it is determined that an event period may be in progress, and baseline updates are immediately stopped, keeping the current baseline model parameters frozen to prevent event signals from contaminating the baseline estimation, causing the baseline to shift towards higher energy directions and weakening the sensitivity of subsequent detections. Both the first threshold and the retention coefficient can be remotely adjusted by the master controller via UART configuration frames to adapt to environmental differences in different installation locations (such as seasonal changes in cable tension caused by temperature differences between shady and sunny slopes).

[0035] Event detection; based on the feature vector of the current analysis window The submodule calculates Mahalanobis distance in real time using the latest baseline model. The calculation method is as follows:

[0036] in The th feature vector of the current analysis window One component; The first of the baseline mean vectors One component; The first of the baseline diagonal covariance vectors The component represents the first component. The variance of each characteristic component under normal background vibration; As a scalar, it reflects the overall deviation of the current window signal from the normal baseline state. Its dimensions are independent of the physical units of each characteristic component, allowing for direct comparison across installation scenarios. When When the threshold is exceeded, the analysis window is marked as an abnormal frame candidate; when several consecutive analysis windows exceed the threshold, the window is marked as an abnormal frame candidate. When all values ​​exceed the second threshold, the submodule confirms entry into event capture mode. The default value for the number of consecutive confirmation windows is 3. This parameter supports remote configuration and is used to balance the false trigger rate and detection latency under different noise environments. The second threshold is remotely issued by the main controller via UART based on the module serial number and historical baseline quality assessment results.

[0037] Double-buffered pre-trigger retention: The submodule maintains a double-buffered structure to retain pre-trigger precursor data. The two buffers are independently allocated in SRAM, and concurrent access safety is ensured through interrupt priority control. One is a rolling history buffer, employing a circular buffer structure. It is continuously written to by the sampling interrupt service routine at the highest priority, storing the complete original sampling data of the most recent windows in units of analysis windows. New data automatically overwrites the oldest data, ensuring the history buffer always retains the original waveform before the event. Taking an STM32F407 (192KB SRAM), 2kHz sampling rate, and three-axis int16 format (6 bytes per sample point) as an example: the program stack, heap, and peripheral buffers occupy approximately 44KB in total, leaving 64KB for the rolling history buffer, which can continuously store approximately 10.7 seconds of three-axis original sampling data, covering the typical duration of a rockfall precursor. The other is an event capture buffer, activated when the event capture mode is triggered. It is dedicated to storing the continuous complete waveform after the event occurs. In the above specific embodiment, 64KB is allocated, with approximately 20KB remaining for other runtime variables.

[0038] When the event capture mode is triggered, the submodule atomically freezes the write pointer of the rolling history buffer by temporarily disabling the sampling interrupt. It then copies the precursor data (i.e., the complete sequence of original sampling points before the trigger moment) stored in the buffer to the event capture buffer as the precursor segment of the event data packet. After copying, the sampling interrupt is restored. Subsequently, newly sampled original data is continuously appended to the event capture buffer as the main impulse segment. The event capture buffer adopts a circular write structure. When the buffer is full, the newly written main impulse segment data overwrites the oldest precursor segment data in the buffer, ensuring that the integrity of the main impulse segment and the decay segment is preserved before the precursor segment, consistent with the core concern of this invention regarding the non-reproducibility of impulse events. When the Mahalanobis distance... After the event frequency drops below the third threshold (the third threshold is lower than the second threshold to prevent the event mode from repeatedly entering and exiting due to signal fluctuations during attenuation) and remains quiet for several consecutive quiet windows, the submodule exits the event capture mode. It then packages the complete event data packets (including the precursor segment, main impulse segment, and attenuation segment) in the event capture buffer and actively reports them to the master controller via UART. The master controller encapsulates these packets into channel data frames of the high-frequency complete event packet type. During non-event capture periods, the submodule only actively reports the statistical summary (root mean square, peak value, and mean value) of the current analysis window to the master controller at fixed intervals, encapsulating it into channel data frames of the high-frequency statistical summary type.

[0039] The standardized data frames from each channel output in step S2 are fed into subsequent steps in a unified format. Due to their irreplaceable value for landslide analysis, high-frequency complete event packets are marked as high priority in the offline cache priority sorting in step S4 to ensure that event packet data is preserved first when storage resources are limited.

[0040] S3 receives heartbeat frames and UART communication data from each channel, adopts a hardware and software combined circuit breaker strategy with heartbeat timeout and CRC error rate as dual criteria, and outputs an updated type configuration table and fault alarm message. Based on the module type configuration table established in S1, steps S3 and S2 run in parallel within the system, continuously monitoring the health of each channel that is in normal operation. An independent heartbeat monitoring thread periodically polls the communication status of each channel to ensure the long-term stable operation of the system in harsh outdoor electrical environments.

[0041] The master controller maintains an independent heartbeat monitoring context for each record in the type configuration table that is in normal operation. This context includes a heartbeat counter (recording the number of heartbeat cycles since the last valid heartbeat), the system timestamp of the last received heartbeat, the total UART frame reception count and CRC check failure count in the current sliding statistics window, and the current communication quality ratio calculated based on these two counts. For the high-frequency RS485 vibration acquisition module and the high-precision analog signal acquisition module, the sub-module actively sends heartbeat frames to the master controller via UART at fixed intervals. The heartbeat frame format includes a frame header identifier, a slot identifier field, an operating status byte (including the sub-module's local temperature warning bit, power supply voltage warning bit, and MCU abnormal flag bit), and a frame tail CRC8 check field. When the master controller receives a valid heartbeat frame that has passed CRC8 verification, it clears the heartbeat counter of the corresponding channel and updates the last heartbeat timestamp. For a typical RS485 acquisition module, if the master controller receives a valid response frame within a specified time after sending a query frame, it will update the heartbeat timestamp of that channel to the current time, using the arrival of the response frame as proof of the channel's heartbeat survival. If a frame with a failed CRC8 verification is received (regardless of the module type), only the CRC verification failure count of the current sliding statistics window of that channel will be incremented by one, without updating the heartbeat timestamp.

[0042] The master control's heartbeat monitoring thread polls the heartbeat context of all normal channels at fixed intervals: if the time difference between the last heartbeat timestamp and the current polling time for a channel exceeds the fourth threshold (the fourth threshold is a multiple of the standard heartbeat cycle length, providing a certain jitter tolerance range), then the channel is determined to have experienced a heartbeat timeout anomaly; if the ratio of the CRC check failure count to the total number of received frames in the current sliding statistics window for the channel exceeds the fifth threshold, then the UART communication link quality for the channel is determined to have severely degraded, possibly caused by interference, cable damage, or abnormal module RF components. The failure of either of these two conditions triggers a fault isolation process. The two conditions are detected independently and are not dependent on each other, to cover different types of fault modes—the former corresponds to complete power failure or MCU crash, and the latter corresponds to scenarios with continuous electrical noise interference but where the module has not completely failed.

[0043] The fault isolation process is executed synchronously at both the software and hardware levels. Operations at both levels are completed within the same monitoring thread polling session, ensuring consistency between software and hardware states. At the software level, the main controller immediately sends a stop signal to the acquisition task thread corresponding to the slot. After the thread safely exits, it destroys the protocol parser instance, disables the transmit / receive function of the corresponding UART port, updates the status flag of the record in the type configuration table from normal operation to fault isolation, and sets the isolation timestamp to the current system time. Simultaneously, the main controller constructs a fault alarm message, recording the fault type (heartbeat timeout or communication quality degradation), slot number, occurrence timestamp, and the last valid heartbeat time. The alarm message is then pushed into the cloud reporting queue managed by S4 for persistence and uploading.

[0044] At the hardware level, the electrical protection of each physical slot is composed of three independent components working together. Starting from the motherboard's 5V power rail, the protection passes sequentially through a PTC thermistor (connected in series in the power supply circuit; its resistance increases sharply during continuous overcurrent to limit the current, and it automatically returns to a low-resistance conduction state after the fault is cleared, requiring no manual replacement and adapting to the maintenance-free requirements of unattended nodes), a MOSFET power control switch (connected in series in the power supply circuit, driven by the main controller's GPIO control line; when the software triggers the fault isolation process, the main controller issues a power-off command to cut off the 5V power supply output of the slot), and reaches the slot's 5V power supply pin; a TVS transient voltage suppressor diode is connected in parallel between the slot's 5V power supply pin and ground, clamping the line voltage to a safe range within microseconds when a lightning surge arrives, absorbing surge energy and preventing downstream components from being damaged by transient high voltage; a soft-start protection circuit is also configured at the slot connector to limit the inrush current at the moment of module insertion, preventing it from impacting the motherboard's power rail. The three protection devices each have their own function: the TVS diode absorbs surge voltage locally, preventing high voltage from being conducted to the PTC and MOSFET; the PTC limits current during continuous overcurrent, protecting the MOSFET from being burned out; and the MOSFET completely cuts off power supply after the software determines a fault, so that the electrical shock generated by the faulty module is blocked in the independent power domain of the slot, and cannot spread to the sub-modules of other healthy slots or the power rail of the main control processor through the motherboard shared power bus.

[0045] The isolated channel is persistently recorded in the type configuration table as a fault isolation state. It does not participate in the acquisition scheduling of S2, and the UART port resources it occupies remain in a closed state, without affecting the normal UART communication of other channels. When maintenance personnel complete the field module replacement and insert the new module into the slot, the GPIO rising edge detection mechanism of S1 will re-trigger the enumeration handshake process. After successful enumeration, the recorded state will be reset to normal operation, and the corresponding acquisition task instance will be activated, realizing the automatic restoration of the full function of the channel. The output of step S3 is a continuously updated type configuration table (including the current operating status and fault isolation records of each channel) and fault alarm messages pushed into the reporting queue. These two outputs are respectively passed to S4 for data management priority judgment, and to S5 for identifying whether there are sub-modules that need remote firmware repair.

[0046] S4 aggregates standardized heartbeat frames and fault alarm messages from various channels, adopts UART delay compensation clock calibration and hierarchical offline caching breakpoint resume method, outputs a time-continuous cloud data sequence and maintains cloud MQTT connection; Based on the standardized data frames continuously output by each channel in S2, the fault alarm messages generated in S3, and the current network link status maintained by the main controller, step S4 uniformly implements data storage and transmission management: when the network is normal, data is pushed to the cloud in real time and the clock synchronization accuracy across sub-modules is maintained; when the network is interrupted, it seamlessly switches to offline hierarchical caching mode to preserve critical event data with the principle of zero loss; after the network is restored, historical data is retransmitted in an orderly manner according to time sequence using the breakpoint resume method, so that the time series received by the cloud is monotonically increasing in the time dimension and has no missing segments.

[0047] The network monitoring submodule of the main controller periodically sends lightweight probe packets to the Ethernet gateway address and the 4G network public address, combined with the connection keep-alive mechanism of the MQTT client, to continuously maintain one of the three network states: Ethernet online, 4G online, and dual-path disconnection. With at least one link remaining online, the main controller sequentially pushes channel data frames from S2 and fault alarm messages from S3 into the MQTT uplink publish queue, which is then delivered to the cloud broker by the MQTT client. The MQTT protocol's QoS1 message acknowledgment mechanism ensures that each message is successfully acknowledged by the cloud at least once during network availability; messages awaiting acknowledgment are temporarily stored in a persistent queue within the client.

[0048] UART latency compensation clock calibration; the clock synchronization mechanism operates in parallel while the network is online. The main control board is equipped with an independent hardware RTC module (with a backup battery). When the network is available, it requests accurate time from the Internet time server via the SNTP protocol and corrects the Linux system clock, while simultaneously writing the calibration results to the hardware RTC. During network outages, the Linux system clock is continuously maintained by the hardware RTC. The cumulative drift of the main control clock during the outage does not exceed ±2 seconds per 24 hours. After the network is restored, the clock can be resynchronized via SNTP, and the relative continuity of the main control timestamp can be used to perform post-timeline correction of offline data. After completing its own time synchronization, the main control board initiates a periodic clock calibration process for each submodule.

[0049] Submodule clock calibration leverages the precise calculability of UART serial transmission delay under known communication parameters. For a given baud rate... (Unit: bps) and fixed byte length (Unit: bytes) calibration frame, its one-way transmission duration on the UART link The calculation method is as follows: the total number of bytes in the frame Multiply by 10 (the number of bits per byte in UART frame format, including 1 start bit, 8 data bits, and 1 stop bit), then divide by the baud rate. ,Right now:

[0050] As a deterministic constant, it is unaffected by network jitter and can be precisely calculated in advance on the main control side. The calibration process is executed as follows: The main control calls the high-precision monotonic clock interface of the Linux system to record the current precise time. The UART transmission operation for the calibration frame is then initiated; the UART receive interrupt of the STM32 submodule is triggered when the first byte of the calibration frame is received. The first instruction of the interrupt service routine at the entry point reads the current count value of the hardware timer, which corresponds to the local time of the submodule. After the master controller sends a compensation query frame, the submodule transmits the count value back via UART; the master controller then converts the transmitted count value into the submodule's local time. The expected arrival time on the main control side Compare and calculate the clock skew compensation amount. :

[0051] in The start time for the master controller to send the calibration frame; The above formula represents the UART one-way transmission delay. The local time is calculated from the local timer count value read when the UART receive interrupt of the submodule is triggered; A positive value indicates that the submodule clock is ahead of the main controller, while a negative value indicates that the submodule clock is behind the main controller. The main controller will... The calibration is encapsulated in integer microseconds and sent in the next calibration frame. Upon receiving the frame, the submodule corrects the count bias of its local RTC, bringing the deviation between its local clock and the master clock to the microsecond level. This calibration process is executed at fixed intervals to continuously offset the long-term frequency drift of the crystal oscillators in each submodule, maintaining the continuous alignment of the timestamps of each submodule with the master global clock. The default calibration interval is 60 seconds. Actual testing has verified that the cumulative drift of the crystal oscillators of each submodule between two adjacent calibrations does not exceed ±3 microseconds, and the deviation between the timestamps of each submodule and the master global clock after calibration converges to within ±5 microseconds.

[0052] Tiered offline caching: When the network monitoring submodule detects that both links are interrupted, the system immediately switches to offline caching mode, employing a two-tiered strategy to adapt to scenarios with different interruption durations. The first tier is the on-chip SRAM cache of each submodule's MCU: The master controller broadcasts frames via UART to notify each submodule to enter offline caching state. The submodule writes subsequently generated data frames with local timestamps into its local circular buffer in chronological order, while maintaining a used capacity counter. High-frequency complete event packets, due to their data volume and engineering value far exceeding statistical summaries, are prioritized for writing to the buffer and are retained rather than discarded when the buffer is nearing full. Existing statistical summary data is evicted in chronological order when capacity is tight, thus achieving priority preservation of critical event data. The master controller periodically polls the used capacity of each submodule's buffer via UART. When the buffer usage of a submodule exceeds the sixth threshold, the master controller sends a read request via UART to read the backlogged data in the submodule's buffer in batches. The second level is a persistent cache on an external high-capacity storage device: the main controller sequentially appends data read from each submodule to an external eMMC or other high-capacity storage device in batches, using time slices as the unit. During writing, two timestamp fields are added to each record—a local timestamp from the submodule's MCU local RTC (which may have accumulated deviations during prolonged network outages) and a global timestamp from the main controller's Linux system clock, continuously maintained by the hardware RTC. This dual timestamp design ensures that even if the submodule's local clock drifts during a network outage, the timeline of each sensor's data can still be reconstructed based on the relative continuity of the main controller's global timestamp after network recovery, without losing the value of cross-sensor data temporal correlation analysis.

[0053] After network recovery, the master MQTT client reconnects and first reads the backlogged offline data from external storage. It then pushes this data into the MQTT uplink queue in batches according to the order of write time, using time slices as the unit. After prioritizing the retransmission of historical offline data in chronological order, it resumes the normal uplink process for subsequent real-time data frames generated in S2, ensuring that the data stream received by the cloud is continuous and ordered on the timeline. The external storage space corresponding to the historical data slices successfully received by the cloud broker is then released for reuse in the next offline cache cycle. The output of step S4 is the complete data sequence received by the cloud MQTT Broker—this sequence consists of time-continuous, consistent-precision multi-sensor data frames, serving as the direct input for the cloud-based disaster early warning system to perform multi-sensor time-series correlation analysis.

[0054] S5, relying on cloud-based MQTT connection and module type configuration table, adopts multi-link redundancy switching and two-level cascaded OTA packet verification and rollback mechanism to output a full system firmware upgrade result report; Based on the cloud data channel established and continuously maintained by S4, and the system status configuration maintained by S3, the S5 step achieves two system-level functions: First, it maintains smooth redundant switching between Ethernet and 4G dual links during the entire system operation to ensure the continuous availability of the data uplink channel; second, it securely and reliably transmits and executes firmware upgrade instructions issued by the cloud to the main control or any sub-module, completing the firmware iteration of the entire system while ensuring zero loss of business data.

[0055] The multi-link redundancy switching mechanism is implemented based on the network monitoring submodule of S4. Upon startup, the master controller simultaneously establishes two independent sessions with the cloud MQTT Broker—an Ethernet MQTT session and a 4G MQTT session. Both sessions subscribe to the same control command topics (including OTA command topics and parameter configuration topics). Data publishing is prioritized through the Ethernet session (low power consumption, stable throughput). The 4G session maintains a connection but does not publish data while the Ethernet session is active (only maintaining a keep-alive heartbeat for rapid switching). When the Ethernet MQTT session's keep-alive heartbeat times out, the master controller immediately switches subsequent data publishing and control command reception to the 4G MQTT session. This switching logic is transparent to the upper-layer services from S2 to S4 and requires no awareness from the upper layers. After the Ethernet connection is restored, it automatically switches back to the Ethernet session as the primary session. The Bluetooth interface serves as a local near-field debugging channel, allowing field maintenance personnel to directly connect to the gateway via mobile terminals to perform local parameter queries and configuration modifications when both WANs are disconnected, without participating in the cloud data transmission process.

[0056] When the cloud-based firmware upgrade management platform needs to perform a firmware update on a module, it publishes an OTA command packet to the OTA command topic subscribed to by the currently active MQTT session on the gateway. The content fields of the command packet include the target module serial number (which corresponds one-to-one with the serial number recorded in the type configuration table established by S1, used for precise target targeting), the Base64 encoded content of the firmware binary data (or the secure download address and authentication token of the cloud firmware file), and the SHA256 checksum of the firmware content. After receiving the OTA command packet, the master controller first calculates the SHA256 digest of the firmware content (if it is a download address, it is downloaded completely to the local buffer first), and compares it byte by byte with the digest field carried in the command packet. Only if the two are completely consistent will the subsequent upgrade process continue; otherwise, the OTA request is discarded and an alarm message with a code indicating the reason for the verification failure is immediately reported to the cloud to prevent the firmware from being tampered with or damaged during network transmission and then mistakenly written to the target device.

[0057] The first stage of the two-level cascaded OTA is directed towards the main controller itself. When the target serial number in the OTA command packet matches the device identifier stored in the main controller, the main controller first notifies all online submodules to enter local autonomous caching state via a UART broadcast frame before executing a reboot. After receiving the notification, each submodule writes the subsequently generated data to its local SRAM circular buffer, consistent with the submodule behavior in the S4 offline caching mode. Subsequently, the main controller executes a dual-partition update strategy: writing the complete firmware to the currently inactive backup system partition. After writing, it performs an independent SHA256 integrity secondary verification on the backup partition content. After both verifications pass, it modifies the active partition identifier in the bootloader configuration file and then executes a controlled system reboot. After rebooting, the new firmware starts normally in the backup partition. If the new firmware completes all initialization processes within a set time and sends a running confirmation signal to the bootloader monitoring process, the bootloader permanently promotes the backup partition to the new primary partition. If the confirmation signal does not arrive within the timeout period, the bootloader automatically reverts the active partition identifier to the old primary partition before the update, and automatically loads the old firmware on the next reboot, completing the automatic rollback. After the main controller restarts and resumes normal operation, it immediately sends a restart completion notification to each submodule. Upon receiving the notification, each submodule reports the backlogged data cached locally to the main controller. The main controller then pushes the data into the MQTT uplink queue in chronological order to be retransmitted to the cloud, achieving zero loss of business data during the restart process.

[0058] The second level of the two-level cascaded OTA is submodule-oriented. When the target sequence number in the OTA command packet matches the sequence number recorded in the type configuration table for a submodule whose status is normal operation, the master controller acts as the relay server for the firmware upgrade of that submodule, responsible for reliably transmitting firmware data on the UART internal link between the master controller and the submodule. The master controller divides the complete submodule firmware verified by SHA256 into several sequentially numbered data packets according to the maximum payload capacity of the current UART transmission frame. Each data packet consists of a packet sequence number field, a payload byte number field, a firmware data field, and a CRC32 check field. The CRC32 field covers the entire content of this data packet (sequence number, length, and data) to detect single-packet transmission errors. The master controller sends packets sequentially via UART to the target submodule's Bootloader receiving channel, in ascending order of sequence number. Upon receiving each packet, the submodule's Bootloader performs a CRC32 check on its CRC32 field. If the check passes, it writes the firmware data of that packet to the target Flash sector by the offset and sends a reception acknowledgment frame carrying the packet's sequence number back to the master controller. If the master controller does not receive an acknowledgment frame for the corresponding sequence number within the timeout period before sending the next packet, it retransmits the packet with that sequence number. The number of retransmissions is subject to a preset upper limit. If this limit is exceeded, the master controller determines that the OTA communication is terminated, sends an abort frame to the submodule, and the submodule's Bootloader reverts to the original firmware partition for startup. The master controller then reports an OTA failure alarm of communication interruption type to the cloud. After all data packets have been received, the submodule bootloader performs a full CRC32 check on the written firmware content. This checksum is pre-calculated and carried in the OTA command packet by the cloud. If the two match, the submodule's boot partition identifier is switched and a software reset of the submodule's MCU is triggered. The submodule then restarts in the new firmware partition. If the full CRC32 check fails, the bootloader abandons the boot partition switch, the submodule restarts in the original firmware partition, and reports a response frame containing a failure reason code to the master controller. The master controller encapsulates the reason code and forwards it to the cloud alarm topic. During the submodule OTA, the target submodule's acquisition task is paused by the master controller, while the acquisition, preprocessing, and data transmission of other slot channels remain unaffected, and the MQTT connection of the baseboard is maintained continuously.

[0059] Regardless of whether the target is the main controller itself or a sub-module, after the OTA process is completed, the main controller will publish an upgrade result message to the upgrade result reporting topic of the MQTT Broker in the cloud. The message includes the target module serial number, the firmware version number before this upgrade, the target firmware version number, the final upgrade result (one of four states: successful completion, active rollback, communication interruption, and verification failure), and a detailed failure reason code (in the case of non-successful state).

[0060] In one embodiment of the present invention, a single monitoring node deployed on a hillside along an inter-provincial highway is used as a specific example. This node is located in the mountainous region of southwest my country, is unattended, and relies on solar power and a 4G network. The node slot configuration is as follows: slot 1 is equipped with a high-frequency RS485 vibration acquisition module (MEMS triaxial accelerometer, sampling rate 2kHz), slot 2 is equipped with a high-precision analog acquisition module (vibrating wire tension sensor, 4–20mA input), slot 3 is equipped with a common RS485 acquisition module (temperature and humidity sensor, acquisition frequency 1 time / second), and slot 4 is empty.

[0061] After the system is powered on, step S1 sequentially completes GPIO rising edge detection and UART enumeration handshake for slots 1 to 3. The type configuration table initialization results are shown in Table 1.

[0062] Table 1. Enumeration and registration results of each slot after system power-on

[0063] After the system powers on, the high-frequency module in slot 1 immediately enters a silent initialization period (default 300 seconds). During this period, the heartbeat timer operates normally, and the heartbeat monitoring of S3 is effective for this channel. Simultaneously, the submodule continuously collects data and stores the feature vectors of each analysis window into the initialization sample buffer, without performing event detection. After the silent period ends, the submodule calculates the median and median absolute deviation for each feature component of all samples in the buffer, completing the baseline model initialization. It then switches to the exponential smoothing update mode triggered by the quiet period condition. After approximately 5 hours of system operation, the baseline model has fully converged, the root mean square amplitude baseline of the background vibration stabilizes at approximately 0.11g, the Mahalanobis distance remains below 1.5 during the quiet period, and baseline updates proceed normally.

[0064] A rockfall impact event occurred around 13:22 on the same day. The characteristics of representative channel data frames reported by slot 1 during this event are shown in Table 2. The data comes from the actual acquisition records of this node.

[0065] Table 2. Characteristics of representative channel data frames in slot 1 during the rockfall impact event.

[0066] Frame number 2 corresponds to the start of the precursor phase: the root mean square amplitude rises to 0.29g, exceeding the first threshold, the baseline update immediately freezes, the Mahalanobis distance of 3.4 exceeds the second threshold, and the submodule begins continuous acknowledgment counting. The table only lists representative frames; between frame number 2 and frame number 3, there are several statistical summary frames with Mahalanobis distances continuously exceeding the second threshold (each frame interval is 128 milliseconds). Continuous acknowledgment counting is completed within this period (default 3 windows, approximately 384 milliseconds). After the acknowledgment count meets the conditions, the submodule enters event capture mode, atomically copying the approximately 10-second precursor raw waveform stored in the rolling history buffer to the event capture buffer. This copying operation and the subsequent UART transmission delay together constitute the approximately 2.1-second time interval between frame number 2 and frame number 3, consistent with the technical solution description. Frame number 3 is the first frame reported after the event capture mode is activated, with a root mean square amplitude of 1.92g and a Mahalanobis distance of 13.7. Frame number 4 corresponds to the main impact segment, with a root mean square amplitude of 4.67g and a Mahalanobis distance of 41.2, far exceeding the normal background level. At frame number 5, the Mahalanobis distance drops to 4.8, below the third threshold, and the continuous quiet window count meets the exit condition. The submodule exits the event capture mode and reports the complete event data packet containing the precursor segment, main impact segment, and decay segment to the master controller via UART. After being encapsulated by S4, it is pushed to the cloud MQTT Broker.

[0067] Approximately 90 seconds after the event (13:24:03), the thunderstorm accompanying the rockfall caused the heartbeat frames of slot 1 to exceed the fourth threshold for an extended period without reaching the required time. The heartbeat monitoring thread of S3 triggered a fault isolation process: On the software side, the acquisition thread of slot 1 was suspended and the corresponding UART port was disabled; on the hardware side, the main control GPIO control line drove the MOSFET switch to cut off the 5V power supply to slot 1, and the TVS diode and PTC thermistor worked together to limit the surge current. Other slots and network communication remained unaffected. Complete impact waveform data during the event (including the precursor segment, approximately 10 seconds of raw sampling sequence, corresponding to approximately 120KB of data) was successfully pushed to the cloud MQTT Broker by S4 before the isolation was triggered, providing complete and accurate time-series data support for subsequent landslide dynamics modeling and protective facility assessment.

[0068] The embodiments of the present invention have been described above. However, the embodiments are not limited to the specific implementation methods described above. The specific implementation methods described above are merely illustrative and not restrictive. Those skilled in the art can make more equivalent embodiments under the guidance of the present embodiments, and all of them are within the protection scope of the present embodiments.

Claims

1. A control method for an edge computing multi-protocol adaptive hot-swappable sensor gateway, characterized in that, Includes the following steps: S1, acquire the physical slot level transition signal, use GPIO dual-edge debouncing detection and UART enumeration handshake protocol to establish a module type configuration table carrying hardware type identifier and serial number; S2, activates the scene-specific adaptive acquisition strategy according to the module type configuration table, uses adaptive high-speed baseline modeling and double-buffered pre-trigger retention mechanism to complete high-frequency edge preprocessing, and outputs standardized heartbeat frames for each channel; S3 receives heartbeat frames and UART communication data from each channel, adopts a hardware and software combined circuit breaker strategy with heartbeat timeout and CRC error rate as dual criteria, and outputs an updated type configuration table and fault alarm message. S4 aggregates standardized heartbeat frames and fault alarm messages from various channels, adopts UART delay compensation clock calibration and hierarchical offline caching breakpoint resume method, outputs a time-continuous cloud data sequence and maintains cloud MQTT connection; S5, relying on cloud-based MQTT connections and module type configuration tables, adopts multi-link redundancy switching and a two-level cascaded OTA packet verification and rollback mechanism to output a full system firmware upgrade result report.

2. The edge computing multi-protocol adaptive hot-swappable sensor gateway control method according to claim 1, characterized in that, In S1, after the GPIO interrupt controller of the baseboard senses the rising edge transition, the hot-plug daemon process performs debouncing judgment. If the time interval between the previous rising edge event of the same slot is less than the preset debouncing time window, the current event is ignored; otherwise, an enumeration frame is sent to the UART port bound to the slot. After the master controller sends an enumeration frame, it starts a response waiting timer. If no response frame is received within the preset timeout period, the enumeration frame is resent. If no response is received after the number of resentments reaches the preset limit, the slot is recorded as an enumeration failure in the module type configuration table. After parsing the response frame, the main controller dynamically instantiates the corresponding acquisition task object and protocol parser based on the hardware type identifier code, and writes the slot number, serial number, hardware type identifier code and current status flag into the module type configuration table; when the module is physically unplugged, the GPIO detection pin senses the falling edge transition, the daemon process suspends the acquisition task thread and destroys the protocol parser instance, and updates the status flag of the corresponding record in the module type configuration table to "unregistered".

3. The edge computing multi-protocol adaptive hot-swappable sensor gateway control method according to claim 1, characterized in that, In S2, the submodule MCU extracts a three-dimensional feature vector from the sampled data within each fixed-length analysis window. The three components of the three-dimensional feature vector are, in order: the root mean square of the three-axis resultant acceleration amplitude, the zero-crossing rate of the three-axis resultant acceleration sequence, and the approximate centroid value of the time-domain segmented bandpass energy weighted spectrum. The method for calculating the approximate value of the spectral centroid is as follows: the sampled sequence is passed through three sets of IIR bandpass filters to extract the filtered output sequences of the low-frequency band, mid-frequency band and high-frequency band respectively. The energy value of the frequency band is obtained by summing the square values ​​of each sampling point of each set of filtered output sequences. The approximate value of the spectral centroid is obtained by dividing the weighted sum of the center frequency of each frequency band and the corresponding energy value by the sum of the energy values ​​of the three frequency bands.

4. The edge computing multi-protocol adaptive hot-swappable sensor gateway control method according to claim 3, characterized in that, In S2, after the submodule is powered on, it enters a silent initialization period. During this period, the three-dimensional feature vector is continuously extracted and stored in the initialization sample buffer. After the silent initialization period ends, the median of each feature component is calculated as the initial mean vector, and the median of the absolute deviation of each feature component is calculated and its square is used as the corresponding component of the initial diagonal covariance vector. The baseline model consists of a mean vector and a diagonal covariance vector. When the root mean square magnitude component of the three-dimensional feature vector is lower than a first threshold, it is determined to be a quiet period, and the mean vector and diagonal covariance vector are updated in an exponential smoothing manner. When the root mean square magnitude component exceeds the first threshold, the baseline model parameters are frozen and updates are stopped.

5. The edge computing multi-protocol adaptive hot-swappable sensor gateway control method according to claim 4, characterized in that, In S2, the Mahalanobis distance is calculated based on the three-dimensional feature vector and the baseline model in the current analysis window. The Mahalanobis distance is a scalar value obtained by summing the square of the difference between each feature component and the corresponding mean vector component, dividing by the corresponding diagonal covariance vector component, and then taking the square root. When the Mahalanobis distance exceeds the second threshold, it is marked as an abnormal frame candidate; When the Mahalanobis distance of a preset number of consecutive analysis windows exceeds the second threshold, the submodule enters the event capture mode.

6. The edge computing multi-protocol adaptive hot-swappable sensor gateway control method according to claim 5, characterized in that, In S2, the submodule maintains a double buffer structure. The first is a rolling history buffer, which uses a circular buffer structure to continuously store the original sampled data. The second is an event capture buffer, which is activated when entering the event capture mode. When the event capture mode is triggered, the submodule atomically freezes the write pointer of the rolling history buffer, copies the precursor data in it to the event capture buffer as the precursor segment, and then appends the newly sampled data as the main impulse segment; when the Mahalanobis distance drops back below the third threshold and maintains a continuous quiet window, it exits the event capture mode and reports the complete event data packet containing the precursor segment, the main impulse segment and the decay segment to the master controller via UART.

7. The edge computing multi-protocol adaptive hot-swappable sensor gateway control method according to claim 1, characterized in that, In S3, for the sub-module in the active reporting mode, the master controller updates the heartbeat timestamp of the corresponding channel when it receives a heartbeat frame that has passed CRC verification; for the sub-module in the passive response mode, the master controller updates the heartbeat timestamp of the channel when it receives a valid response frame after sending a query frame. The master's heartbeat monitoring thread polls each channel at fixed intervals: if the time difference between the last heartbeat timestamp and the current time of a certain channel exceeds the fourth threshold, the heartbeat timeout is determined. If the ratio of CRC check failure count to the total number of received frames exceeds the fifth threshold, the communication quality is determined to be degraded. Once any condition is met, the fault isolation process is triggered. At the software level, the status of the record in the module type configuration table is updated to fault isolation. At the hardware level, the main controller drives the MOSFET power control switch to cut off the power supply to the slot.

8. The edge computing multi-protocol adaptive hot-swappable sensor gateway control method according to claim 1, characterized in that, In S4, after the master controller corrects its own system clock through the SNTP protocol, it starts the periodic clock calibration process for each sub-module: the master controller records the start time of sending the calibration frame and calculates the UART one-way transmission delay. When the UART receive interrupt is triggered, the sub-module reads the local timer count value and sends it back. The master controller calculates the clock deviation compensation amount based on this and sends it to the sub-module to correct its local clock bias. When both network links are interrupted, the system switches to offline caching mode: the first level is for the sub-module to write data frames into the local circular buffer, and the event data packets are preserved first; the second level is for the master controller to write the backlogged data into the external large-capacity storage in time slices, and each record is appended with the sub-module's local timestamp and the master controller's global timestamp. Once the network is restored, the data will be uploaded to the cloud in chronological order.

9. The edge computing multi-protocol adaptive hot-swappable sensor gateway control method according to claim 1, characterized in that, In S5, the master controller simultaneously establishes an Ethernet MQTT session and a 4G MQTT session, prioritizes publishing data through the Ethernet session, switches to the 4G MQTT session when the Ethernet session is disconnected, and automatically switches back when the Ethernet session is restored. The first level of the two-level cascaded OTA faces the main controller itself. The main controller writes the firmware to the backup system partition and performs integrity verification. After passing the verification, it switches the active partition identifier and restarts. If the new firmware does not send a running confirmation signal within a preset time, it will automatically fall back to the old partition. The second level is for sub-modules. The main controller divides the firmware into sequentially numbered data packets and sends them one by one to the sub-module Bootloader via UART. Each packet is written to the target Flash sector after being checked by CRC32. After all data packets are received, an overall check is performed. If the check passes, the boot partition is switched and reset. If the check fails, the system reverts to the original firmware partition.

10. An edge computing multi-protocol adaptive hot-swappable sensor gateway, used to perform the steps in the edge computing multi-protocol adaptive hot-swappable sensor gateway control method as described in any one of claims 1-9, characterized in that, include: The hot-swap enumeration module is used to collect physical slot level transition signals. It adopts GPIO dual-edge debouncing detection and UART enumeration handshake protocol to establish a module type configuration table carrying hardware type identifier and serial number. The scene-specific acquisition and edge preprocessing module is used to activate the scene-specific adaptive acquisition strategy according to the module type configuration table. It adopts adaptive high-speed baseline modeling and double-buffered pre-trigger retention mechanism to complete high-frequency edge preprocessing and outputs standardized data frames for each channel. The heartbeat monitoring and fault isolation module is used to receive heartbeat frames and UART communication data from each channel. It adopts a hardware and software combined circuit breaker strategy with heartbeat timeout and CRC error rate as dual criteria, and outputs an updated type configuration table and fault alarm messages. The data transmission and clock calibration module is used to aggregate standardized data frames and fault alarm messages from various channels. It adopts UART delay compensation clock calibration and hierarchical offline caching breakpoint resume method to output a time-continuous cloud data sequence and maintain the cloud MQTT connection. The communication switching and OTA upgrade module is used to output a full system firmware upgrade result report by relying on the cloud MQTT connection and module type configuration table, adopting multi-link redundancy switching and a two-level cascaded OTA packet verification and rollback mechanism.

Images