Multi-interface data distribution method and system of multi-interface gateway
By acquiring signals in multiple formats and processing edge computing, combined with the MQTT protocol and Ethernet communication, the flexibility and real-time issues of traditional data distribution methods are solved, achieving comprehensive and accurate data acquisition, ensuring orderly accessibility of data transmission and the system's intelligence level.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- KUNMING HUALONGZHITENG TECH CO LTD
- Filing Date
- 2026-02-04
- Publication Date
- 2026-05-01
AI Technical Summary
Traditional data distribution methods cannot be flexibly adjusted to adapt to different signal types and communication environments, lack edge computing capabilities, resulting in incomplete data collection, insufficient accuracy and reliability, and lack of QoS level settings for data transmission, affecting data integrity and availability, and lacking real-time and intelligent linkage mechanisms.
The system acquires analog, digital, and RS-485 bus signals through a multi-standard signal acquisition module, performs range conversion, linear calibration, and outlier removal, and combines MQTT protocol and Ethernet communication to achieve data packaging and uploading, and performs intelligent linkage processing locally to ensure orderly data accessibility and real-time response.
It achieves comprehensive and accurate data collection, ensures orderly and accessible data transmission, enhances the system's intelligence level, and improves response speed and automation.
Smart Images
Figure CN121967217A_ABST
Abstract
Description
A method and system for multi-interface data distribution in a multi-interface gateway Technical Field
[0001] This invention relates to the field of data distribution technology, specifically to a multi-interface data distribution method and system for a multi-interface gateway. Background Technology
[0002] Currently, traditional methods typically rely on fixed hardware configurations and software settings, making them inflexible and unable to adapt to specific application needs. This limits the system's adaptability to different signal types and communication environments, and it can only process specific signal types, failing to simultaneously support multiple signal formats. This results in insufficient comprehensiveness in data acquisition, potentially missing important information.
[0003] Furthermore, traditional methods typically lack edge computing capabilities, making it impossible to process and analyze data in real time. For example, they lack functions such as range conversion, linear calibration, and outlier removal, making it difficult to guarantee the accuracy and reliability of the data. Moreover, traditional data transmission methods often lack QoS level settings, which can easily lead to packet loss, duplication, or out-of-order delivery, affecting the integrity and availability of the data. Additionally, the issuance and execution of control commands often take a long time, lacking real-time performance. The absence of intelligent linkage mechanisms prevents the system from reacting quickly to real-time data, reducing the level of automation. Summary of the Invention
[0004] To achieve the above objectives, the present invention provides the following technical solution: a multi-interface data distribution method for a multi-interface gateway, comprising: acquiring gateway configuration parameters and operating strategies for each signal acquisition channel loaded through a Web visual configuration interface; wherein, the gateway configuration parameters include MQTT connection parameters, device unique credentials, and communication protocol parameters for each interface; according to the operating strategy, periodically polling and acquiring analog signals, digital signals, and dual-channel RS-485 bus signals through a multi-standard signal acquisition module to obtain raw acquisition data; wherein, the multi-standard signal acquisition module includes an analog acquisition module, a digital I / O module, and a dual-channel RS485 interface module; and inputting the raw acquisition data into a unified edge number... The data processing module performs range conversion, linear calibration, and outlier removal to obtain standardized real-time data. The edge data processing module cleans the data based on a preset threshold and a sliding window algorithm. The data packaging module encapsulates the standardized real-time data, gateway identity, precise timestamp, and event type into a unified format data frame to be distributed. This data frame follows a JSON format or binary frame structure and is categorized according to topic rules. Using an Ethernet communication module and an MQTT client, the data frame is uploaded to the cloud server based on the MQTT connection parameters. A QoS level is selected based on data importance, and a message identifier is introduced when the QoS is greater than or equal to 1 to ensure orderly data delivery.
[0005] Preferably, according to the operating strategy, the analog signal, digital signal, and dual-channel RS-485 bus signal are periodically polled and acquired through the multi-standard signal acquisition module to obtain raw acquisition data. This includes: acquiring four independent analog input signals through the analog acquisition module, selecting pull-up resistors or shunt resistors according to the signal type configured on the Web interface, converting the analog voltage or current signal into an ADC digital signal, and performing preliminary conversion based on the configured range coefficient and decimal precision to obtain the raw analog data; acquiring the device dry contact or 24V signal through the digital I / O module, performing debouncing processing on the signal status according to the configured input filtering logic and toggle strategy to obtain digital status data; polling the slave device according to the Modbus RTU protocol through the dual-channel RS-485 interface module, reading register data according to the configured device address, baud rate, and function code, and parsing the register value into engineering unit values according to the set byte order rules to obtain bus protocol data; and summarizing the raw analog data, digital status data, and bus protocol data into the raw acquisition data.
[0006] Preferably, the data packaging module is invoked to encapsulate the standardized real-time data, gateway identity, precise timestamp, and event type into a unified format data frame to be distributed. This includes: obtaining the current system time calibrated by RTC or NTP mechanism and generating a precise timestamp containing year, month, day, hour, minute, second, and millisecond; reading the gateway's unique device ID stored locally and the site information configured via the Web to generate a hierarchical publishing topic; filling the standardized real-time data, precise timestamp, and gateway's unique device ID into a preset data frame template, and adding a sequence number for retransmission deduplication to the frame header to generate a data frame to be distributed; performing CRC verification on the generated data frame to be distributed and appending the checksum to the frame tail.
[0007] Preferably, the method further includes: receiving control commands issued by a cloud server or a local rule engine before uploading data using an Ethernet communication module and an MQTT client; wherein the control commands are obtained by subscribing to a specific downlink topic; inputting the control commands into a local intelligent linkage engine and comparing them with the current standardized real-time data; wherein the local intelligent linkage engine supports threshold triggering, interval judgment, slope calculation, and DI triggering logic; if the comparison result meets the preset linkage rules, directly outputting control signals through a digital I / O module or an RS-485 interface module to drive the field actuator; wherein, in case of conflict, multiple control commands are processed according to priority and a mutual exclusion table.
[0008] Preferably, the method further includes: monitoring the network link status and Broker connection status in real time when uploading data using the Ethernet communication module and MQTT client; when a network anomaly or connection unreachable is detected, writing the currently generated data frame to be distributed into a built-in circular buffer; wherein the circular buffer uses Flash or FRAM media and has power-off data protection function; after the network is restored and reachable, reading all historical data frames stored in the circular buffer and reassembling them in chronological order according to the timestamp and sequence number in the frame; retransmitting the reassembled historical data frame through the MQTT client and performing a timestamp-based deduplication operation in the cloud.
[0009] Preferably, the data frame to be distributed is uploaded to the cloud server using an Ethernet communication module and an MQTT client based on the MQTT connection parameters, including: parsing the header identifier of the data frame to be distributed to determine whether the data type is telemetry data or event alarm; if it is telemetry data, then directly sending it using the QoS level 0 publishing strategy; if it is an event alarm, then selecting the QoS level 2 publishing strategy and assigning a message identifier; establishing a TCP connection with the cloud broker, pushing the data frame to be distributed to the designated queue according to the generated publishing topic; receiving the PUBACK or PUBREC acknowledgment message returned by the cloud broker, and marking the data with the corresponding message identifier as delivered.
[0010] Preferably, the method further includes: when the gateway is powered on, executing a hardware self-test program to detect the power supply voltage, Flash integrity, and status of each communication link; if the self-test passes, reading historical operation logs and network dialing test results from non-volatile memory; if the self-test fails, triggering a watchdog reset mechanism and illuminating a fault indicator light; and based on the self-test results and the read historical data, initializing the Ethernet controller and peripheral drivers of the main control MCU.
[0011] Preferably, the control command is input into the local intelligent linkage engine and compared with the current standardized real-time data, including: parsing the target register address or target I / O port number in the control command; extracting the current status value associated with the target register or target I / O port from the standardized real-time data; comparing the current status value with the set value in the control command to determine whether the start-up conditions are met; if the start-up conditions are met, generating an execution command containing the target address and action code.
[0012] Preferably, the method further includes: during gateway operation, real-time acquisition of the power supply current and chip junction temperature of each interface module; when the power supply current exceeds the overcurrent protection threshold or the chip junction temperature exceeds the high temperature threshold, generating a frequency reduction command; sending the frequency reduction command to the main control MCU to reduce the data transmission rate of the Ethernet communication module and the sampling rate of the analog quantity acquisition module; recording the occurrence time and duration of the frequency reduction event, and uploading it to the cloud operation and maintenance platform via a heartbeat packet.
[0013] A multi-interface data distribution system for a multi-interface gateway, applicable to the aforementioned multi-interface data distribution method for a multi-interface gateway, includes: an interface configuration unit for acquiring gateway configuration parameters and operating strategies for each signal acquisition channel loaded via a Web visual configuration interface; wherein the gateway configuration parameters include MQTT connection parameters, device unique credentials, and communication protocol parameters for each interface; a signal acquisition unit for periodically polling and acquiring analog signals, digital signals, and dual-channel RS-485 bus signals through a multi-standard signal acquisition module according to the operating strategy to obtain raw acquisition data; wherein the multi-standard signal acquisition module includes an analog acquisition module, a digital I / O module, and a dual-channel RS485 interface module; and a data processing unit for processing the raw acquisition data. A unified edge data processing module performs range conversion, linear calibration, and outlier removal to obtain standardized real-time data. This module cleans the data based on preset thresholds and a sliding window algorithm. A data packaging unit calls the data packaging module to encapsulate the standardized real-time data, gateway identity, precise timestamps, and event types into a unified format data frame to be distributed. This data frame follows a JSON format or binary frame structure and is categorized according to topic rules. A communication unit uses an Ethernet communication module and an MQTT client to upload the data frame to the cloud server based on the MQTT connection parameters. A QoS level is selected based on data importance, and a message identifier is introduced when the QoS is greater than or equal to 1 to ensure orderly data delivery.
[0014] Compared with the prior art, the beneficial effects of the present invention are: (1) The present invention loads gateway configuration parameters through a Web visual interface. Users can flexibly configure MQTT connection parameters, device credentials and communication protocols according to actual needs and application scenarios. This flexibility enables the system to adapt to different signal acquisition needs and communication environments. Moreover, the multi-standard signal acquisition module can process analog, digital and RS-485 bus signals at the same time, ensuring the comprehensiveness of data acquisition. The edge data processing module ensures the accuracy and reliability of data through range conversion, linear calibration and outlier removal. (2) The present invention ensures the orderly accessibility of data in the network transmission process by setting QoS levels and introducing message identifiers, reducing the risk of data loss and duplication. Moreover, the local intelligent linkage engine can compare the control instructions issued by the cloud with real-time data to realize condition-triggered automatic control, improving the intelligence level and response speed of the system. Attached Figure Description
[0015] Figure 1 is a schematic flowchart of the overall method in one embodiment of the present invention; Figure 2 is a schematic diagram of the system architecture of the overall system in one embodiment of the present invention.
[0016] In the diagram: 1. Interface configuration unit; 2. Signal acquisition unit; 3. Data processing unit; 4. Data packaging unit; 5. Communication unit. Detailed Implementation
[0017] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0018] Example 1, please refer to Figure 1. This invention provides a technical solution: a multi-interface data distribution method for a multi-interface gateway, comprising: S1, acquiring gateway configuration parameters and operating strategies of each signal acquisition channel loaded through a Web visual configuration interface; wherein, the gateway configuration parameters include MQTT connection parameters, device unique credentials, and communication protocol parameters of each interface; S2, according to the operating strategy, periodically polling and acquiring analog signals, digital signals, and dual-channel RS-485 bus signals through a multi-standard signal acquisition module to obtain raw acquisition data; wherein, the multi-standard signal acquisition module includes an analog acquisition module, a digital I / O module, and a dual-channel RS485 interface module; S3, inputting the raw acquisition data into a unified... The edge data processing module performs range conversion, linear calibration, and outlier removal to obtain standardized real-time data. Specifically, the edge data processing module cleans the data based on preset thresholds and a sliding window algorithm. S4: The data packaging module encapsulates the standardized real-time data, gateway identity, precise timestamps, and event types into a unified format data frame to be distributed. This data frame follows a JSON format or binary frame structure and is categorized according to topic rules. S5: Using the Ethernet communication module and MQTT client, the data frame to be distributed is uploaded to the cloud server based on MQTT connection parameters. The QoS level is selected based on data importance, and a message identifier is introduced when the QoS is greater than or equal to 1 to ensure orderly data delivery.
[0019] It should be noted that users configure the gateway's parameters through a web-based visual interface. These parameters include MQTT connection information (for communication with the cloud), the device's unique identifier, and communication protocol parameters for each interface. This stage is fundamental to ensuring the gateway can connect and interact correctly. Based on the user-defined operating strategy, the gateway uses a multi-format signal acquisition module to periodically acquire different types of signals. These signals include analog signals (e.g., temperature or pressure), digital signals (e.g., switch status), and dual RS-485 bus signals (for communication between industrial devices). In this way, the gateway can acquire data from various sensors and devices. The raw acquired data is then sent to the edge data processing module. Here, the data undergoes range conversion, linear calibration, and outlier removal to ensure standardized real-time data; this step is crucial for improving data quality and reliability. The processed data is then packaged into data frames of a unified format. These frames contain not only standardized real-time data but also gateway identification, timestamps, and event types. The data frames adhere to specific formats, such as JSON or binary, and are categorized according to topic rules for subsequent processing and storage. Through an Ethernet communication module and an MQTT client, the gateway uploads the data frames to be sent to the cloud server according to pre-configured MQTT connection parameters. During this process, the importance of the data is considered when selecting... Different Quality of Service (QoS) levels are selected to ensure that critical data reaches its destination in an orderly manner. For example, suppose a manufacturing company has installed multiple sensors in its factory to monitor the operating status of various devices, including temperature, pressure, and switch sensors. The company wants to upload this data to the cloud for analysis via a multi-interface gateway. The gateway parameters are configured through a web-based visual configuration interface, including MQTT connection information, unique device credentials (such as device IDs), and communication protocols for each interface. These settings ensure that the gateway can successfully communicate with the cloud server. After configuration, the gateway begins data collection according to the set strategy. It uses a multi-standard signal acquisition module to... The system periodically polls the temperature sensor to acquire analog signals, such as the current temperature value; simultaneously, it checks digital signals, such as whether a machine is on; it also reads data from other industrial devices via an RS-485 interface; this data is recorded as raw acquisition data; this raw data is transmitted to the edge data processing module; here, the temperature values may need to be converted to units (e.g., from Fahrenheit to Celsius) and linearly calibrated to ensure the accuracy of the temperature sensor readings; at the same time, any outliers, such as extreme temperature readings caused by sensor malfunctions, are also identified and rejected to ensure the reliability of the final data; after processing, the standardized real-time data (such as Celsius temperature, on / off status, etc.) are packaged into a data frame;This data frame includes not only the actual temperature value but also the gateway's identification, such as the device ID, a precise timestamp indicating the data collection time, and the event type (e.g., "temperature update"). Assuming the data frame is in JSON format and its structure meets the transmission requirements, the gateway uses its Ethernet communication module and MQTT client to upload this packaged data frame to the company's cloud server. During the upload process, a Quality of Service (QoS) level is selected for each data point based on its importance. If the temperature data is critical, a QoS level of 1 might be chosen to ensure reliable, sequential transmission of the data.
[0020] In an optional embodiment, according to the operating strategy, analog signals, digital signals, and dual-channel RS-485 bus signals are periodically polled and acquired through a multi-standard signal acquisition module to obtain raw acquisition data. This includes: acquiring four independent analog input signals through an analog acquisition module, selecting pull-up resistors or shunt resistors according to the signal type configured on the Web interface, converting analog voltage or current signals into ADC digital signals, and performing preliminary conversion based on the configured range coefficients and decimal precision to obtain raw analog data; acquiring device dry contact or 24V signals through a digital I / O module, performing debouncing processing on the signal status according to the configured input filtering logic and toggle strategy to obtain digital status data; polling slave devices through a dual-channel RS-485 interface module according to the Modbus RTU protocol, reading register data according to the configured device address, baud rate, and function code, and parsing the register values into engineering unit values according to the set byte order rules to obtain bus protocol data; and summarizing the raw analog data, digital status data, and bus protocol data into raw acquisition data.
[0021] It should be noted that the analog signal acquisition module can simultaneously accept four independent analog signal inputs; these signals may be in the form of voltage or current. Based on the settings in the web configuration interface, appropriate pull-up resistors or shunt resistors are selected to process these signals, converting the analog signals into digital signals readable by the ADC (Analog-to-Digital Converter). Then, combined with the user-configured range coefficients and decimal precision, these digital signals undergo preliminary conversion to obtain preliminary raw analog data. The digital I / O module receives the dry contact signal or 24V digital signal from the acquisition device. During this process, according to the configured input filtering logic and toggle strategy, the signal status is de-jittered to eliminate false alarms or jitter caused by signal interference, ultimately obtaining stable digital status data. The dual RS-485 interface module communicates with the slave device according to the Modbus RTU protocol. This process includes configuring the slave device's address, setting the communication baud rate, and specifying the function code to read the required register data. After reading, the values of these registers are parsed according to the set byte order rules and converted into engineering unit numbers. This process ensures that the data acquired from the equipment accurately reflects the actual situation. The analog raw data, digital status data, and bus protocol data obtained after processing by the above three modules are summarized into a complete set of raw acquisition data. This data provides comprehensive information on the status of the field equipment and lays the foundation for subsequent analysis and processing. For example, suppose a multi-interface gateway is used in the management of a smart greenhouse to monitor environmental conditions and control equipment. This gateway contains temperature sensors, humidity sensors, and some switch control devices. To achieve efficient monitoring, the gateway needs to periodically collect different types of data. The gateway collects temperature and humidity signals in the environment through the analog acquisition module. The temperature sensor outputs an analog voltage signal of 0 to 10 volts, while the humidity sensor provides a current signal of 4 to 20 milliamps. Technicians set the pull-up resistor of the temperature sensor in the Web configuration interface to stabilize the reading and selected an appropriate range factor and decimal precision. Through the analog-to-digital converter, the analog signals of temperature and humidity are converted into digital signals, and the final analog raw data indicates that the current temperature is 25.3 degrees Celsius and the humidity is 60%.5%; The gateway acquires the switch status via digital I / O modules; for example, the switch signal of an irrigation pump is 24V; when the water level sensor detects that the water level is too low, the switch is triggered; the switch signal is debouncing according to the configured input filtering logic to ensure that the read status is a stable "on" or "off" state, and finally obtains digital status data indicating that the irrigation pump is currently in the "on" state; the gateway uses a dual RS-485 interface module to communicate with several connected greenhouse controllers; these controllers feed back data via the Modbus RTU protocol, such as the register values of the soil moisture sensor; according to the configured device address and baud rate, the gateway successfully reads the register values; after parsing, these register values are converted into the corresponding engineering units, and the soil moisture is found to be 30%.
[0022] In an optional embodiment, the data packaging module is invoked to encapsulate standardized real-time data, gateway identity, precise timestamp, and event type into a unified format data frame to be distributed. This includes: obtaining the current time calibrated by RTC or NTP mechanism and generating a precise timestamp containing year, month, day, hour, minute, second, and millisecond; reading the gateway's unique device ID stored locally and the site information configured via the Web to generate a hierarchical publishing topic; filling the standardized real-time data, precise timestamp, and gateway's unique device ID into a preset data frame template, and adding a sequence number for retransmission deduplication to the frame header to generate a data frame to be distributed; performing CRC verification on the generated data frame to be distributed and appending the checksum to the frame tail.
[0023] It should be noted that a Real-Time Clock (RTC) or Network Time Protocol (NTP) mechanism is used to obtain the current time. This time is recorded as a precise timestamp containing year, month, day, hour, minute, second, and millisecond to ensure that the data frame contains accurate time information, facilitating subsequent data analysis and event tracking. Before publishing data, it is necessary to read the gateway's unique device ID stored locally and the site information configured via the web. This information is used to construct a hierarchical topic, enabling data to be correctly classified and routed during message transmission. The hierarchical topic typically includes information such as device type and location, ensuring that the recipient can quickly identify the data source. Standardized real-time data, precise timestamps, and the gateway's unique device ID are used to construct the hierarchical topic. The backup ID is entered into the preset data frame template; a sequence number is added at the beginning of the data frame for retransmission deduplication, ensuring that the receiver does not process duplicate data due to network problems; to ensure data integrity and accuracy, a Cyclic Redundancy Check (CRC) is performed on the generated data frame, calculating a checksum and appending it to the end of the data frame; this helps the receiver verify the validity of the received data and reduces data corruption caused by transmission errors; a specific example: suppose there is an environmental monitoring system in a smart city, in which multiple sensor nodes are deployed to monitor air quality and meteorological data in real time; each node is equipped with a gateway to collect and send data; during a data collection process, a certain network... The gateway collects air quality data via sensors, including a PM2.5 concentration of 35 micrograms per cubic meter and a temperature of 22 degrees Celsius. To distribute this data to the cloud platform, the gateway initiates a data packaging module. The gateway uses an NTP service to obtain the current time, assuming it's January 6, 2026, 08:30:15 and 250 milliseconds. This precise timestamp will be used as the time information in the data frame. The gateway reads its unique device ID from local storage, such as "GW123456," and learns from the web configuration that the gateway is located at "CityPark." Combining this information, a hierarchical publishing topic is generated, possibly "environment / ". CityPark / GW123456; The previously collected standardized real-time data (PM2.5 concentration and temperature), along with the precise timestamp (2026-01-06T08:30:15.250) and the gateway's unique device ID (GW123456), are filled into a preset data frame template; a sequence number, such as "001", is added to the beginning of the data frame for detection and deduplication during data retransmission; the gateway performs CRC checks on the generated data frames, calculates a checksum, such as "ABCD1234", and then appends this checksum to the end of the data frame; the resulting data frame to be distributed may contain the following information: Frame header: sequence number "001"; standardized real-time data: PM2.5.Concentration 35%, temperature 22%; Precise timestamp: 2026-01-06T08:30:15.250; Gateway unique device ID: GW123456; Hierarchical publishing topic: environment / CityPark / GW123456; Frame end: CRC checksum "ABCD1234".
[0024] In an optional embodiment, the method further includes: receiving control commands issued by a cloud server or a local rule engine before uploading data using an Ethernet communication module and an MQTT client; wherein the control commands are obtained by subscribing to a specific downlink topic; inputting the control commands into a local intelligent linkage engine and comparing them with the current standardized real-time data; wherein the local intelligent linkage engine supports threshold triggering, interval judgment, slope calculation, and DI triggering logic; if the comparison result meets the preset linkage rules, directly outputting control signals through a digital I / O module or an RS-485 interface module to drive the field actuator; wherein, in case of conflict, multiple control commands are processed according to priority and a mutual exclusion table.
[0025] It should be noted that the device communicates with the cloud server or local rules engine via an Ethernet communication module to receive control commands. These commands are subscribed to through specific downlink topics, meaning the device periodically checks for new commands. Once a control command is received, it is input into the local intelligent linkage engine. This engine uses current standardized real-time data (such as sensor data) to perform conditional comparisons with the received control commands. The intelligent linkage engine supports various logical judgments, including threshold triggering (triggered when a value exceeds or falls below a set threshold), interval judgment (triggered when a value is within a specified range), slope calculation (triggered when the rate of change reaches a certain condition), and digital input (DI) triggering logic. If the comparison result matches the preset linkage rules, such as a sensor value exceeding a specific threshold, a control signal will be output through the digital I / O module or RS-485 interface module to drive the field actuators (such as alarms, fans, etc.). When multiple control commands are received simultaneously, if conflicts exist, these commands will be handled according to preset priorities and mutual exclusion tables to ensure the rationality and effectiveness of execution. For example, suppose a smart agriculture system deploys some environmental monitoring sensors... Primarily used to monitor soil moisture and temperature, and communicate with the cloud via the MQTT protocol; configured for automatic irrigation adjustment; on a certain day, the cloud server sends a control command to all connected devices, requesting "start irrigation when soil moisture is below 30%"; this command is subscribed to and received by the devices through a specific downlink topic; after receiving this command, the device's Ethernet communication module transmits it to the local intelligent linkage engine; simultaneously, soil moisture is being monitored in real time, assuming the current sensor reading is 25%; at this point, the intelligent linkage engine compares the control command with the current moisture data; because when The initial humidity (25%) is lower than the threshold (30%) set in the control command, and the comparison result meets the preset linkage rules. Therefore, the intelligent linkage engine decides to take action; it sends a control signal through the digital I / O module to activate the irrigation water valve and start watering; during this process, if another control command is received at the same time, such as "turn off the water pump when the temperature is higher than 35°C", and the current temperature sensor reading is 36°C, this command conflicts with the irrigation command; it will continue to execute the irrigation operation according to the preset priority rules (e.g., irrigation priority is higher than turning off the water pump), without being affected by the temperature control command.
[0026] In an optional embodiment, the method further includes: monitoring the network link status and Broker connection status in real time when uploading data using the Ethernet communication module and MQTT client; when a network anomaly or connection unreachability is detected, writing the currently generated data frame to be distributed into a built-in circular buffer; wherein the circular buffer uses Flash or FRAM media and has power-off data protection function; after the network becomes reachable again, reading all historical data frames stored in the circular buffer and reassembling them in chronological order according to the timestamp and sequence number in the frame; retransmitting the reassembled historical data frame through the MQTT client and performing a timestamp-based deduplication operation in the cloud.
[0027] It's important to note that the device continuously checks the network link status and connection to the Broker via the Ethernet communication module and MQTT client. This means the device can constantly monitor network activity, ensuring smooth data upload. If a network anomaly or unreachable connection to the Broker is detected during monitoring, the currently distributed data frames are not immediately lost. Instead, these frames are written to a built-in circular buffer. This buffer uses Flash or FRAM storage and has power-loss protection, ensuring data integrity even during power outages or restarts. Once the network is restored, the device reads all previously stored historical data frames from the circular buffer. Based on the timestamps and sequence numbers within the frames, it reassembles the data in chronological order, ensuring correct transmission sequence. The reassembled data frames are then resent to the cloud via the MQTT client. In the cloud, deduplication is performed based on timestamps to ensure no duplicate data is recorded, thus maintaining data integrity and accuracy. For example, in a smart home, a temperature sensor periodically reports indoor temperature to the cloud. The device... Data is uploaded using the MQTT protocol, and an Ethernet communication module is used to maintain the connection with the cloud broker. Under normal circumstances, the temperature sensor sends the current temperature data to the cloud every minute. However, one day, due to a network failure, the device cannot connect to the broker, resulting in the inability to upload temperature data. At this time, the network anomaly is detected, and the connection is determined to be unreachable, rather than abandoning the data. Assuming that the current temperature reading of the temperature sensor is 22°C, the data frame generated from this data is written to the built-in circular buffer. This buffer uses FRAM storage medium to ensure that the temperature data will not be lost even if the device is powered off. After a few minutes of network failure, the network connection is restored. The device begins to read the stored historical data frames from the circular buffer. Assuming that three data frames are collected during this period, with temperatures of 22°C, 21.5°C, and 23°C, each data frame has a corresponding timestamp and sequence number. These three data frames are sorted to ensure that they are reassembled in chronological order. Then, it sends these data frames to the cloud sequentially through the MQTT client. After receiving the data, the cloud uses the timestamp to deduplicate, avoiding duplicate records.
[0028] In an optional embodiment, an Ethernet communication module and an MQTT client are used to upload data frames to be distributed to a cloud server based on MQTT connection parameters. This includes: parsing the header identifier of the data frame to be distributed to determine whether the data type is telemetry data or an event alarm; if it is telemetry data, then selecting a QoS level 0 publishing strategy to send it directly; if it is an event alarm, then selecting a QoS level 2 publishing strategy and assigning a message identifier; establishing a TCP connection with the cloud broker and pushing the data frames to be distributed to a designated queue according to the generated publishing topic; receiving a PUBACK or PUBREC acknowledgment message returned by the cloud broker and marking the data with the corresponding message identifier as delivered.
[0029] It's important to note that the data frames to be sent are parsed, with particular attention paid to their header identifiers. This information helps determine the data type, such as whether it's telemetry data (e.g., temperature and humidity readings from sensors) or an event alarm (e.g., an alarm triggered by a smoke detector). Different Quality of Service (QoS) policies are used for message distribution depending on the data type. If the data type is telemetry data, a QoS level of 0 will be selected, meaning the message will be sent at most once and no acknowledgment is required. If the data type is an event alarm, a QoS level of 2 will be selected to ensure reliable message transmission, and each message will be assigned a unique message identifier. For subsequent confirmation; after confirming the data type and its QoS policy, a TCP connection is established with the Broker in the cloud; this connection is the foundation of the MQTT protocol, allowing data interaction between the device and the cloud; the data frames to be distributed are pushed to the designated queue according to the generated publishing topics; each topic typically represents a specific data category or device type, enabling the cloud to better manage and process data; acknowledgment messages are received from the cloud Broker, such as PUBACK (for QoS0 and QoS1) or PUBREC (for QoS2); upon receiving these acknowledgment messages, the corresponding message identifier is marked as delivered, ensuring that the information has been successfully transmitted. To the cloud; a specific example: Suppose in a smart agriculture monitoring system, some environmental sensors are deployed to monitor soil moisture and temperature; now, the soil moisture sensor generates a data frame to be distributed, containing a reading of 40% current soil moisture; this data frame is parsed, and its header identifier is checked; through parsing, it is found that this is telemetry data, because it is sensor data collected periodically; based on the data type, it is decided to send this data directly using a QoS level 0 publishing policy; a TCP connection is established with the MQTTBroker in the cloud; this connection ensures that the data can be transmitted stably and securely; then, the generated publishing topic (e.g., "Agriculture / Soil Moisture") is combined with the current soil moisture reading. Soil moisture data frames are combined and pushed to a designated queue in the cloud. After the data is uploaded, the cloud broker returns a PUBACK acknowledgment message. Upon receiving this acknowledgment, the soil moisture data is marked as delivered, indicating that the data has been successfully uploaded and can be processed by the cloud. Simultaneously, assuming a smoke detector triggers an alarm, generating an event alarm data frame, this data frame is parsed again. Since it is an event alarm, a QoS level 2 publishing policy is adopted, and a unique message identifier is assigned to this message. A TCP connection is then established, and the event alarm data frame is pushed to the corresponding topic in the cloud (e.g., "Agriculture / Alarm").Upon receiving the PUBREC acknowledgment message from the cloud broker, the data for this event alert will be marked as delivered, ensuring that any potential message loss issues are properly handled.
[0030] In an optional embodiment, the method further includes: when the gateway is powered on, executing a hardware self-test program to detect the power supply voltage, Flash integrity, and status of each communication link; if the self-test passes, reading historical operation logs and network dialing test results from non-volatile memory; if the self-test fails, triggering a watchdog reset mechanism and illuminating a fault indicator light; and based on the self-test results and the read historical data, initializing the Ethernet controller and peripheral drivers of the main control MCU.
[0031] It's important to note that after the gateway starts running, it first checks several key hardware parameters. Specifically, it checks whether the power supply voltage is normal, the integrity of the Flash memory (ensuring no damage or data loss), and the status of each communication link (e.g., whether the connection to external devices is normal). If the self-test results show everything is normal, it reads historical operating logs and network test results from non-volatile memory. This information can be used to analyze the device's past performance and help determine if there are any potential problems. If any problems are found during the self-test, a watchdog reset mechanism is triggered. The watchdog is a monitoring mechanism that automatically restarts the device when a fault occurs to prevent it from freezing. Simultaneously, a fault indicator light illuminates to alert the user of the fault. Based on the self-test results and the read historical data, it initializes the Ethernet controller and other peripheral drivers of the main microcontroller (MCU). These initialization operations ensure that the device can connect to the network and communicate with the outside world. For example, suppose there is a smart water monitoring gateway responsible for monitoring and managing the city's water supply. When this gateway device powers on, it first executes a hardware self-test program. During the self-test, the gateway first checks the power supply voltage to ensure it is within the normal range. If the voltage is too low, the device will not function properly. Next, the gateway will check the integrity of the Flash memory to ensure that previously stored data and programs are not corrupted. Finally, the gateway will also check the communication links with the water meter and other sensors to ensure they are functioning correctly, such as confirming successful connection to a remote water meter. Assuming the self-test results show all items are normal, the gateway will continue to read historical operating logs and network test results from non-volatile memory. For example, it may read water supply data from the past 24 hours, communication status records, and any previously occurring alarm information. This historical data can help understand the device's operating efficiency and whether adjustments or maintenance are needed. If unstable power supply voltage or an error is found in the Flash memory during the self-test, the watchdog reset mechanism will be triggered immediately to attempt to restart the device to restore normal operation. Simultaneously, the fault indicator light will illuminate, visually alerting the user to a problem with the device. Once the self-test passes and historical data is successfully read, the Ethernet controller of the main control MCU will be initialized to ensure the gateway can connect to the network and transmit data with the cloud server. At the same time, various peripheral drivers (such as those used to control valves and pumps) will also be initialized to ensure proper control.
[0032] In an optional embodiment, the control command is input into the local intelligent linkage engine and compared with the current standardized real-time data, including: parsing the target register address or target I / O port number in the control command; extracting the current status value associated with the target register or target I / O port from the standardized real-time data; comparing the current status value with the set value in the control command to determine whether the start-up conditions are met; if the start-up conditions are met, generating an execution command containing the target address and action code.
[0033] It's important to note that the process involves parsing control instructions. These instructions typically contain the address of a target register or the number of a target I / O port, indicating the specific location to be operated on. For example, the target register might be a location storing the current temperature value, while the target I / O port number might point to a controllable device such as an electric valve. Once the target register or I / O port is identified, the current status value related to that target is extracted from standardized real-time data. These status values reflect the current operating status of the device, such as temperature, pressure, or the on / off state of the device. The extracted current status value is compared with the target value set in the control instruction. This step is crucial because it determines whether the start-up conditions are met. If the current status value reaches the set value, it is considered that the next step can proceed. If the judgment result indicates that the start-up conditions are met, an execution instruction is generated. This instruction contains the target address (register or I / O port) and an action code (e.g., turning on, off, or adjusting the device) so that subsequent operations can be executed smoothly. A concrete example is provided. Imagine a smart home system where a user sends a control command via a mobile app, wanting to set the air conditioner temperature to 22 degrees Celsius. The user's command includes a target register address pointing to the air conditioner's temperature setting register (e.g., address 0x01). When the control command is input to the local smart home engine, it first parses the command and confirms the target register address is 0x01. Next, it extracts the current air conditioner status value from standardized real-time data, for example, finding that the current temperature setting is 25 degrees Celsius. It compares the extracted current temperature setting of 25 degrees Celsius with the target value of 22 degrees Celsius set by the user in the control command. Since the current status value of 25 degrees Celsius is greater than the setting value of 22 degrees Celsius, this means the activation condition is met (i.e., the air conditioner needs to cool down). An execution command is generated, containing the target address 0x01 and an action code, indicating that the air conditioner's temperature setting should be changed to 22 degrees Celsius. This execution command is then sent to the air conditioner control module to actually execute the user's request.
[0034] In an optional embodiment, the method further includes: during gateway operation, real-time acquisition of the power supply current and chip junction temperature of each interface module; when the power supply current exceeds the overcurrent protection threshold or the chip junction temperature exceeds the high temperature threshold, generating a frequency reduction command; sending the frequency reduction command to the main control MCU to reduce the data transmission rate of the Ethernet communication module and the sampling rate of the analog quantity acquisition module; recording the occurrence time and duration of the frequency reduction event, and uploading it to the cloud operation and maintenance platform via a heartbeat packet.
[0035] It's important to note that during gateway operation, the device continuously monitors the power supply current and chip junction temperature of each interface module. These two parameters are key indicators of proper device operation. Changes in power supply current may indicate changes in device load, while increased chip temperature can lead to overheating, affecting device performance and lifespan. If the monitored power supply current exceeds the set overcurrent protection threshold, or the chip junction temperature exceeds the high-temperature threshold, a frequency reduction command will be immediately generated. The purpose of the frequency reduction command is to reduce the device load, thereby preventing further damage or malfunction. The frequency reduction command is sent to the main control microcontroller (MCU), instructing it to reduce the data transmission rate of the Ethernet communication module and the sampling rate of the analog signal acquisition module. By reducing the frequency of data transmission and sampling, the device can reduce power consumption and heat generation, thus alleviating overload or overheating issues. The occurrence time and duration of the frequency reduction event are recorded. This data is uploaded to the cloud-based operation and maintenance platform via heartbeat packets, facilitating the operation and maintenance team to analyze and manage the device's operating status and take timely measures. For example, suppose there is an intelligent traffic monitoring gateway responsible for collecting and processing urban traffic data. During the operation of this gateway, it will monitor the power supply current of each interface module in real time. Current and chip junction temperature, for example, in modules used to connect traffic cameras and sensors; on a hot summer day, the chip temperature of the traffic monitoring gateway might rise to 85 degrees Celsius due to the high temperature environment and high load, while the supply current might also reach the overcurrent protection threshold due to the simultaneous connection of multiple high-power sensors; these two abnormalities will be detected immediately; to prevent damage to the device due to overheating or overload, a frequency reduction instruction will be generated; this instruction will require the main control MCU to reduce the data transmission rate of the Ethernet communication module, for example, from sending 1000 data points per second to sending 500 data points per second; At the same time, the sampling rate of the analog acquisition module is reduced from 10 samples per second to 5 samples per second. This frequency reduction measure can effectively reduce power consumption and heat generation, helping the device to stay within a safe operating range. After the frequency reduction event occurs, the time of occurrence of the event will be recorded, such as "January 6, 2026, 08:30", and the duration of the frequency reduction will be recorded, such as lasting 30 minutes. Subsequently, this information will be uploaded to the cloud operation and maintenance platform in the form of heartbeat packets. The operation and maintenance team can see the record of this frequency reduction event, so as to determine whether it is necessary to adjust the device or improve the heat dissipation in subsequent maintenance and analysis.
[0036] Example 2, please refer to Figure 2. This invention provides a technical solution: a multi-interface data distribution system for a multi-interface gateway, applicable to the aforementioned multi-interface data distribution method for a multi-interface gateway, comprising: an interface configuration unit 1, used to acquire gateway configuration parameters and operating strategies of each signal acquisition channel loaded through a Web visual configuration interface; wherein, the gateway configuration parameters include MQTT connection parameters, device unique credentials, and communication protocol parameters of each interface; a signal acquisition unit 2, used to periodically poll and acquire analog signals, digital signals, and dual-channel RS-485 bus signals through a multi-standard signal acquisition module according to the operating strategy, to obtain raw acquisition data; wherein, the multi-standard signal acquisition module includes an analog acquisition module, a digital I / O module, and a dual-channel RS485 interface module; data processing. Unit 3 is used to input the raw collected data into a unified edge data processing module for range conversion, linear calibration, and outlier removal to obtain standardized real-time data. The edge data processing module cleans the data based on preset thresholds and a sliding window algorithm. Unit 4 is used to call the data packaging module to encapsulate the standardized real-time data, gateway identity, precise timestamps, and event types into a unified format data frame to be distributed. The data frame to be distributed follows JSON format or a binary frame structure and is categorized according to topic rules. Unit 5 is used to upload the data frame to be distributed to the cloud server using an Ethernet communication module and an MQTT client based on MQTT connection parameters. The QoS level is selected according to data importance, and a message identifier is introduced when the QoS is greater than or equal to 1 to ensure orderly data delivery.
[0037] The embodiments of the present invention have been described in detail above with reference to the accompanying drawings. However, the present invention is not limited thereto. Various changes can be made within the scope of knowledge possessed by those skilled in the art without departing from the spirit of the present invention.
Claims
1. A method for multi-interface data distribution in a multi-interface gateway, characterized in that, include: The system retrieves gateway configuration parameters and operating strategies for each signal acquisition channel loaded via a web-based visual configuration interface. These gateway configuration parameters include MQTT connection parameters, device unique credentials, and communication protocol parameters for each interface. Based on the operating strategies, the system periodically polls and acquires analog signals, digital signals, and dual-channel RS-485 bus signals using a multi-standard signal acquisition module to obtain raw acquisition data. This multi-standard signal acquisition module includes an analog acquisition module, a digital I / O module, and a dual-channel RS485 interface module. The raw acquisition data is then input into a unified edge data processing module for range conversion, linear calibration, and outlier handling. The data is filtered to obtain standardized real-time data. The edge data processing module cleans the data based on a preset threshold and a sliding window algorithm. The data packaging module encapsulates the standardized real-time data, gateway identity, precise timestamp, and event type into a unified format data frame to be distributed. This data frame follows a JSON format or binary frame structure and is categorized according to topic rules. Using an Ethernet communication module and an MQTT client, the data frame is uploaded to the cloud server based on the MQTT connection parameters. A QoS level is selected based on data importance, and a message identifier is introduced when the QoS is greater than or equal to 1 to ensure orderly data delivery.
2. The multi-interface data distribution method for a multi-interface gateway according to claim 1, characterized in that, According to the aforementioned operating strategy, analog signals, digital signals, and dual-channel RS-485 bus signals are periodically polled and acquired through a multi-standard signal acquisition module to obtain raw acquisition data. This includes: acquiring four independent analog input signals through an analog acquisition module, selecting pull-up resistors or shunt resistors according to the signal type configured on the web interface, converting analog voltage or current signals into ADC digital signals, and performing preliminary conversion based on the configured range coefficients and decimal precision to obtain raw analog data; acquiring device dry contact or 24V signals through a digital I / O module, performing debouncing processing on the signal status according to the configured input filtering logic and toggle strategy to obtain digital status data; polling slave devices through a dual-channel RS-485 interface module according to the Modbus RTU protocol, reading register data according to the configured device address, baud rate, and function code, and parsing the register values into engineering unit values according to the set byte order rules to obtain bus protocol data; and summarizing the raw analog data, digital status data, and bus protocol data into the raw acquisition data.
3. The multi-interface data distribution method for a multi-interface gateway according to claim 2, characterized in that, The data packaging module encapsulates the standardized real-time data, gateway identity, precise timestamp, and event type into a unified format data frame to be distributed. This includes: obtaining the current system time calibrated by RTC or NTP mechanism and generating a precise timestamp containing year, month, day, hour, minute, second, and millisecond; reading the gateway's unique device ID stored locally and the site information configured via the Web to generate a hierarchical publishing topic; filling the standardized real-time data, precise timestamp, and gateway's unique device ID into a preset data frame template, and adding a sequence number for retransmission deduplication to the frame header to generate the data frame to be distributed; performing CRC verification on the generated data frame to be distributed and appending the checksum to the frame tail.
4. The multi-interface data distribution method for a multi-interface gateway according to claim 3, characterized in that, The method further includes: receiving control commands issued by a cloud server or a local rule engine before uploading data using an Ethernet communication module and an MQTT client; wherein the control commands are obtained by subscribing to a specific downlink topic; inputting the control commands into a local intelligent linkage engine and comparing them with the current standardized real-time data; wherein the local intelligent linkage engine supports threshold triggering, interval judgment, slope calculation, and DI triggering logic; if the comparison result meets the preset linkage rules, directly outputting control signals through a digital I / O module or an RS-485 interface module to drive the field actuator; wherein, in case of conflict, multiple control commands are processed according to priority and mutual exclusion tables.
5. The multi-interface data distribution method for a multi-interface gateway according to claim 4, characterized in that, The method further includes: monitoring the network link status and Broker connection status in real time when uploading data using the Ethernet communication module and MQTT client; when a network anomaly or connection unreachable is detected, writing the currently generated data frame to be distributed into a built-in circular buffer; wherein the circular buffer uses Flash or FRAM media and has power-off data protection function; after the network is restored and reachable, reading all historical data frames stored in the circular buffer and reassembling them in chronological order according to the timestamp and sequence number in the frame; retransmitting the reassembled historical data frame through the MQTT client and performing a timestamp-based deduplication operation in the cloud.
6. The multi-interface data distribution method for a multi-interface gateway according to claim 5, characterized in that, Using an Ethernet communication module and an MQTT client, the data frame to be distributed is uploaded to the cloud server based on the MQTT connection parameters. This includes: parsing the header identifier of the data frame to be distributed to determine whether the data type is telemetry data or an event alarm; if it is telemetry data, then selecting QoS level 0 for direct transmission; if it is an event alarm, then selecting QoS level 2 for transmission and assigning a message identifier; establishing a TCP connection with the cloud broker and pushing the data frame to be distributed to a designated queue according to the generated publication topic; receiving a PUBACK or PUBREC acknowledgment message returned by the cloud broker and marking the data with the corresponding message identifier as delivered.
7. The multi-interface data distribution method for a multi-interface gateway according to claim 6, characterized in that, The method further includes: when the gateway is powered on, executing a hardware self-test program to detect the power supply voltage, Flash integrity, and status of each communication link; if the self-test passes, reading historical operation logs and network dialing test results from non-volatile memory; if the self-test fails, triggering a watchdog reset mechanism and illuminating a fault indicator light; and based on the self-test results and the read historical data, initializing the Ethernet controller and peripheral drivers of the main control MCU.
8. The multi-interface data distribution method for a multi-interface gateway according to claim 7, characterized in that, The control command is input into the local intelligent linkage engine and compared with the current standardized real-time data, including: parsing the target register address or target I / O port number in the control command; extracting the current status value associated with the target register or target I / O port from the standardized real-time data; comparing the current status value with the set value in the control command to determine whether the start-up conditions are met; if the start-up conditions are met, generating an execution command containing the target address and action code.
9. The multi-interface data distribution method for a multi-interface gateway according to claim 8, characterized in that, The method further includes: during gateway operation, real-time acquisition of the power supply current and chip junction temperature of each interface module; when the power supply current exceeds the overcurrent protection threshold or the chip junction temperature exceeds the high temperature threshold, generating a frequency reduction command; sending the frequency reduction command to the main control MCU to reduce the data transmission rate of the Ethernet communication module and the sampling rate of the analog quantity acquisition module; recording the occurrence time and duration of the frequency reduction event, and uploading it to the cloud operation and maintenance platform via a heartbeat packet.
10. A multi-interface data distribution system for a multi-interface gateway, applicable to the multi-interface data distribution method for a multi-interface gateway as described in any one of claims 1-9, characterized in that, include: The interface configuration unit is used to acquire gateway configuration parameters and operating strategies for each signal acquisition channel loaded through the Web visual configuration interface; wherein, the gateway configuration parameters include MQTT connection parameters, device unique credentials, and communication protocol parameters for each interface; the signal acquisition unit is used to periodically poll and acquire analog signals, digital signals, and dual-channel RS-485 bus signals through a multi-standard signal acquisition module according to the operating strategy to obtain raw acquisition data; wherein, the multi-standard signal acquisition module includes an analog acquisition module, a digital I / O module, and a dual-channel RS485 interface module; the data processing unit is used to input the raw acquisition data into a unified edge data processing module for range conversion and linearization. The process involves defining and removing outliers to obtain standardized real-time data. The edge data processing module cleans the data based on a preset threshold and a sliding window algorithm. A data packaging unit calls the data packaging module to encapsulate the standardized real-time data, gateway identity, precise timestamps, and event types into a unified format data frame to be distributed. This data frame follows a JSON format or binary frame structure and is categorized according to topic rules. A communication unit uses an Ethernet communication module and an MQTT client to upload the data frame to the cloud server based on the MQTT connection parameters. A QoS level is selected based on data importance, and a message identifier is introduced when the QoS is greater than or equal to 1 to ensure orderly data delivery.