Internet of Things gateway multi-module communication method and device and storage medium

Abstract

The invention relates to the technical field of Internet of Things communication, in particular to an Internet of Things gateway multi-module communication method and device and a storage medium. The method comprises the steps of collecting multi-dimensional information, sorting transmission requests based on a hierarchical rule and generating a scheduling instruction, and performing dynamic matching of transmission resources and communication requirements; establishing a priority queue to distribute data in combination with a communication rule and scheduling information, tracking the progress in real time and finishing coding interaction of a target end; monitoring a multi-dimensional state to construct a matrix, and executing a hierarchical fault-tolerant strategy for channel abnormity, module faults and data loss; the device comprises a communication demand identification and scheduling module, a data distribution module and a communication state fault-tolerant module. Through the above mode, the suitability of the transmission protocol is improved, and the conditions of wrong data transmission and missed data transmission are avoided, so that the efficient and reliable communication requirement in a complex scene is met.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) communication technology, and in particular to a multi-module communication method, apparatus, and storage medium for an IoT gateway. Background Technology

[0002] In IoT systems, seamless communication between devices is the core foundation for realizing intelligent applications. However, the real-world IoT environment is a complex ecosystem composed of heterogeneous devices, heterogeneous networks, and heterogeneous protocols. Currently, there are various communication protocols, such as short-range wireless protocols Zigbee and BLE, industrial bus protocols Modbus and PROFINET, and IP-compatible protocols MQTT and CoAP. These protocols differ significantly in data format, transmission mechanism, and security model, leading to the formation of "protocol silos" between devices.

[0003] Existing multi-module communication solutions for IoT gateways have the following shortcomings in core aspects, making it difficult to meet the needs of efficient and reliable communication in complex scenarios. In the data distribution stage, the existing solutions have a relatively crude distribution mechanism, lacking deep coordination with scheduling instructions. They are not well adapted to the distribution paths and transmission protocol requirements of different business types of data, and have not established a sound priority queue management mechanism, which easily leads to data mis-sending and missing data. Summary of the Invention

[0004] The purpose of this invention is to provide a multi-module communication method, device and storage medium for Internet of Things gateways, which aims to solve the technical problems in the prior art such as insufficient adaptation of data distribution paths and transmission protocol requirements for different business types, lack of a sound priority queue management mechanism, and easy occurrence of data mis-sending and missing data.

[0005] To achieve the above objectives, the present invention provides a multi-module communication method for IoT gateways, applied to IoT gateways that include heterogeneous networks and multi-protocol adaptation modules, comprising the following steps: Collect multi-dimensional information, sort transmission requests based on hierarchical rules and generate scheduling instructions to dynamically match transmission resources with communication requirements; By combining communication rules and scheduling information, a priority queue is constructed to distribute data, track progress in real time, and complete the target end coding interaction; A multi-dimensional status matrix is ​​constructed by monitoring, and a hierarchical fault tolerance strategy is implemented for channel anomalies, module failures, and data loss.

[0006] Among them, the steps of collecting multi-dimensional information, sorting transmission requests based on hierarchical rules and generating scheduling instructions, and dynamically matching transmission resources with communication requirements are as follows: A communication scheduling module establishes a real-time interactive link with each protocol adaptation submodule and collects the connection status information of the submodules; the connection status information includes connection stability, signal strength and access duration; Synchronously collect data transmission request information from each submodule, obtain key attributes such as request initiation time and whether it is an urgent request, and extract the core attributes of the data to be transmitted; the core attributes include protocol type, data volume, real-time level, and business importance tag; A three-dimensional scheduling model is constructed based on hierarchical rules, and transmission requests are logically ordered according to the priority of real-time performance, the auxiliary adaptation of data volume, and the supplementary weighting of business importance.

[0007] After the steps of constructing a three-dimensional scheduling model based on hierarchical rules, and logically sorting and transmitting requests according to real-time priority, data volume for auxiliary adaptation, and business importance for supplementary weighting: Generate scheduling instructions that include channel number, timing plan and transmission order to achieve dynamic matching of transmission resources and communication requirements.

[0008] Among them, the steps of combining communication rules and scheduling information to construct a priority queue for data distribution, tracking progress in real time, and completing the target end encoding interaction are as follows: The main control module receives the verified, uniformly formatted data output by the data relay module and extracts the target receiver identifier from the data; the target receiver identifier includes the address of the target protocol adaptation submodule and the cloud server IP. The system retrieves preset communication rules, divides the distribution paths and transmission protocol requirements for different service types of data, and sends a distribution request to the communication scheduling module in conjunction with the channel allocation information in the scheduling instructions.

[0009] After retrieving preset communication rules, dividing the distribution paths and transmission protocol requirements for different service types of data, and combining the channel allocation information in the scheduling instruction, sending a distribution request to the communication scheduling module: The communication scheduling module responds to requests, invokes the corresponding transmission channel, and constructs a priority distribution queue.

[0010] After the steps of using the communication scheduling module to respond to requests, calling the corresponding transmission channel, and constructing a priority distribution queue: Data distribution is performed in the order of the queue. The transmission progress is tracked in real time through a periodic feedback mechanism, and the distribution status is fed back to the main control module in a synchronous manner. After receiving the data, the target end protocol adaptation submodule completes the encoding conversion and outputs it to the heterogeneous device to complete the data interaction.

[0011] Among them, in the steps of monitoring multi-dimensional status to construct a matrix and implementing hierarchical fault tolerance strategies for channel anomalies, module failures, and data loss: The communication scheduling module constructs a multi-dimensional status monitoring matrix and defines the monitoring dimensions; the monitoring dimensions include transmission channel status, module operation status, and data transmission status. Real-time collection of status parameters from various dimensions; among which transmission channel parameters include transmission rate, bit error rate, transmission delay and channel occupancy rate; module operation parameters include CPU occupancy rate, memory usage rate, power supply voltage and operating temperature; and data transmission parameters include data integrity, whether data is lost and serial number continuity. Preset safety thresholds for each state parameter, compare real-time collected data with the thresholds to determine if there are any abnormal states; Implement tiered fault tolerance processing for different anomaly types.

[0012] Among them, the steps for performing hierarchical fault tolerance processing for different anomaly types are as follows: When a channel malfunctions, switch to the backup channel and update the scheduling instructions; When a module fails, a redundant submodule is activated and the transmission link is reconstructed. When data is lost, a retransmission mechanism is triggered within a preset time window.

[0013] This invention also provides a multi-module communication device for an IoT gateway, comprising a communication demand identification and scheduling module, a data distribution module, and a communication state fault tolerance module; wherein: The communication demand identification and scheduling module is used to collect multi-dimensional information, sort transmission requests based on hierarchical rules and generate scheduling instructions, and dynamically match transmission resources with communication demands. The data distribution module is used to combine communication rules and scheduling information to construct a priority queue for data distribution, track progress in real time, and complete the target end encoding interaction. The communication state fault tolerance module is used to monitor a multi-dimensional state construction matrix and execute a hierarchical fault tolerance strategy for channel anomalies, module failures, and data loss.

[0014] The present invention also provides a computer-readable storage medium storing a computer program, the computer program including program instructions, which, when executed by a processor, cause the processor to execute the IoT gateway multi-module communication method.

[0015] This invention discloses a multi-module communication method, apparatus, and storage medium for an IoT gateway. The method comprises a communication demand identification and scheduling module, a data distribution module, and a communication state fault-tolerant module, performing the following steps: collecting multi-dimensional information; sorting transmission requests based on hierarchical rules and generating scheduling instructions; dynamically matching transmission resources with communication demands; combining communication rules and scheduling information to construct a priority queue for data distribution; tracking progress in real time and completing target-end encoding interaction; monitoring multi-dimensional states to construct a matrix; and implementing hierarchical fault-tolerant strategies for channel anomalies, module failures, and data loss. Through these methods, the adaptability of transmission protocols is improved, and data mistransmission and omissions are avoided, thereby meeting the high-efficiency and reliable communication requirements in complex scenarios. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a flowchart of the steps of the multi-module communication method for the Internet of Things gateway of the present invention.

[0018] Figure 2 This is a flowchart of steps S100 of the present invention.

[0019] Figure 3 This is a flowchart of steps S200 of the present invention.

[0020] Figure 4 This is a flowchart of steps S300 of the present invention.

[0021] Figure 5 This is a schematic diagram of the structure of the multi-module communication device for the Internet of Things gateway of the present invention.

[0022] Figure 6 This is a schematic diagram of the electronic device of the present invention.

[0023] 401 - Communication demand identification and scheduling module, 402 - Data distribution module, 403 - Communication status fault tolerance module. Detailed Implementation

[0024] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application.

[0025] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0026] It should be understood that although the terms first, second, third, etc., may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0027] Please see Figures 1-4 This invention provides a multi-module communication method for an IoT gateway, applicable to an IoT gateway containing heterogeneous networks and multi-protocol adaptation modules, comprising the following steps: S100: Collects multi-dimensional information, sorts transmission requests based on hierarchical rules and generates scheduling instructions, and dynamically matches transmission resources with communication requirements.

[0028] In this implementation, multi-dimensional information is collected, transmission requests are sorted based on hierarchical rules, and scheduling instructions are generated to dynamically match transmission resources with communication requirements. The specific process is as follows: S101: The communication scheduling module establishes a real-time interactive link with each protocol adaptation submodule and collects the connection status information of the submodules; the connection status information includes connection stability, signal strength and access duration; S102: Synchronously collect data transmission request information from each submodule, obtain key attributes such as request initiation time and whether it is an urgent request, and extract the core attributes of the data to be transmitted; among which the core attributes include protocol type, data volume, real-time level and business importance label; S103: Based on hierarchical rules, a three-dimensional scheduling model is constructed. Transmission requests are logically ordered according to the priority of real-time level, the auxiliary adaptation of data volume, and the supplementary weighting of business importance. The scheduling instructions containing channel number, timing plan and transmission order are generated to complete the dynamic matching of transmission resources and communication requirements.

[0029] In the above process, a bidirectional real-time interactive link is established between the communication scheduling module and each protocol adaptation submodule. Real-time data transmission and reception and status feedback are achieved through standardized interfaces (such as SPI and UART interfaces), and connection status information of each submodule is collected synchronously. Specifically, the connection status information includes connection stability (determined by the number of link interruptions within three consecutive communication cycles; ≤1 interruption indicates a stable connection), signal strength (in dBm, ranging from -100dBm to 0dBm; signal strength ≥-80dBm is considered acceptable), and access duration (timed from the moment the submodule successfully accesses the gateway architecture, accurate to the millisecond level). The collection period is set to 10ms to ensure the timeliness of the status information.

[0030] While collecting connection status information, the system simultaneously collects data transmission request information initiated by each protocol adaptation submodule. It obtains key attributes such as request initiation time (accurate to nanoseconds, used to distinguish the initiation order of requests with the same priority) and whether it is an urgent request (determined by the urgent flag bit in the request message; a flag bit of 1 indicates an urgent request, and 0 indicates a normal request) through request message parsing. Simultaneously, it extracts attributes from the data to be transmitted associated with the request. Core attributes include protocol type (such as Zigbee, Modbus, MQTT, BLE, etc., identified and parsed through the data frame header), data size (in bytes, calculating the complete data volume corresponding to a single transmission request), real-time performance level (divided into high, medium, and low levels according to business requirements; high level requires transmission latency ≤10ms, medium level ≤100ms, low level ≤1s, identified through data attribute fields), and business importance tags (divided into critical business and ordinary business; critical business includes device control commands, fault alarm data, etc., and ordinary business includes environmental monitoring data, historical data backup, etc., pre-configured by the gateway).

[0031] Based on pre-defined hierarchical rules, a three-dimensional scheduling model of "real-time performance - data volume - business importance" is constructed. All transmission requests are sorted according to a progressive priority logic, generating precise scheduling instructions and completing resource matching. First, real-time performance level is the core sorting criterion. Transmission requests with high real-time performance level are given priority to occupy high-speed transmission resources, taking precedence over medium and low real-time performance level requests. For requests with the same real-time performance level, data volume is used as a secondary adaptation criterion. A dynamic time-slice round-robin mechanism is used to allocate transmission resources. Requests with larger data volumes (>1MB) are allocated longer time slices (50ms), while requests with smaller data volumes (≤1MB) are allocated shorter time slices (20ms), avoiding congestion caused by small data consuming large amounts of resources. Finally, business importance is used as a supplementary weighting criterion. Requests marked as critical business are assigned a priority weight of 1.2 times and are given priority in the request queue with the same real-time performance and data volume. Based on the above sorting results, a scheduling instruction is generated that includes the transmission channel number (which specifies the physical transmission channel within the corresponding gateway), timing plan (transmission start time and duration for each request), and transmission order. This instruction is then synchronously sent to the main control module and the corresponding protocol adaptation submodule. The main control module allocates the corresponding transmission bandwidth and interface resources according to the instruction, thereby achieving dynamic and precise matching between transmission resources and communication requirements.

[0032] S200: Combining communication rules and scheduling information, it constructs a priority queue to distribute data, tracks progress in real time, and completes target-side encoding interaction.

[0033] In this implementation, a priority queue is constructed to distribute data by combining communication rules and scheduling information, and progress is tracked in real time to complete the target end encoding interaction. The specific process is as follows: S201: The main control module receives the verified unified format data output by the data relay module and extracts the target receiver identifier from the data; the target receiver identifier includes the address of the target protocol adaptation submodule and the cloud server IP. S202: Retrieve preset communication rules, divide the distribution paths and transmission protocol requirements of data of different service types, and send a distribution request to the communication scheduling module in combination with the channel allocation information in the scheduling instruction; S203: The communication scheduling module responds to the request, calls the corresponding transmission channel, and constructs a priority distribution queue; S204: Data distribution operations are performed in the order of the queue. The transmission progress is tracked in real time through a periodic feedback mechanism, and the distribution status is synchronously fed back to the main control module. After receiving the data, the target end protocol adaptation submodule completes the encoding conversion and outputs it to the heterogeneous device to complete the data interaction.

[0034] In the above process, the main control module receives uniformly formatted data output from the data relay module. This data has passed the integrity verification of the data relay module (verifying field integrity and format compliance) to ensure that there is no data corruption or missing data. The main control module parses the uniformly formatted data, extracts the target receiver identifier, and clarifies the data transmission destination. The target receiver identifier includes the target protocol adaptation submodule address (the unique physical address of each submodule within the gateway, used to locate the submodule) and the cloud server IP (the fixed IP address of the cloud receiving node, used in conjunction with the port number for precise location). Simultaneously, data identification information is recorded for subsequent progress tracking and status association.

[0035] The main control module retrieves the gateway's preset communication rule base, which has pre-configured the distribution paths and transmission protocol requirements for different types of business data. For example, critical data for industrial control needs to be distributed through encrypted transmission links, while ordinary data for environmental monitoring can be distributed through conventional links. Transmission to cloud servers requires the MQTT protocol, and transmission to heterogeneous devices needs to be adapted to the protocol type of the corresponding submodule. Combining the channel allocation information in the scheduling instruction generated in step S103, the module confirms the available transmission channels and resource limitations for the current data. After integrating the above information, it sends a data distribution request to the communication scheduling module. The request includes key information such as the target receiver identifier, available channel information, business type, and transmission requirements.

[0036] After receiving a distribution request, the communication scheduling module first verifies the consistency between the request information and the scheduling instruction, confirms the availability of channel resources and whether the distribution path conforms to preset rules. If the verification passes, it responds to the request, invokes the corresponding transmission channel (physical or logical), and constructs a priority distribution queue based on the priority order in the scheduling instruction. Queue construction strictly follows the principle of "critical business data over ordinary business data, high real-time data over medium-to-low real-time data, and urgent request data over ordinary request data." Simultaneously, it associates data identifiers with queue positions to ensure the queue order matches the scheduling instruction and avoids priority confusion.

[0037] The communication scheduling module executes data distribution operations sequentially according to priority queues. It tracks the transmission progress of each data item in real time through a periodic feedback mechanism (feedback period of 5ms), including parameters such as the number of bytes transmitted, remaining transmission volume, transmission time, and transmission rate. Simultaneously, it feeds back the distribution status ("Distributing," "Distributing Completed," "Distribution Error") to the main control module. The main control module updates the data transmission status ledger in real time for anomaly troubleshooting and management. When the data target is a protocol adaptation submodule, the target protocol adaptation submodule receives the unified format data and performs encoding conversion according to its own adapted protocol type (such as Zigbee, Modbus), converting the unified format data into the standard frame format of the corresponding protocol to ensure communication compatibility with heterogeneous devices. After encoding, it outputs the data to the corresponding heterogeneous device through an interface to achieve data interaction. When the data target is a cloud server, the unified format data is uploaded through an encrypted transmission link (using the AES encryption algorithm). After uploading, it receives a confirmation receipt from the cloud and feeds it back to the main control module, completing the entire data distribution and interaction process.

[0038] S300: Monitors multi-dimensional status to build a matrix and implements hierarchical fault tolerance strategies for channel anomalies, module failures, and data loss.

[0039] In this implementation, a multi-dimensional status matrix is ​​constructed based on monitoring, and a tiered fault-tolerance strategy is implemented for channel anomalies, module failures, and data loss. The specific process is as follows: S301: The communication scheduling module constructs a multi-dimensional status monitoring matrix and defines the monitoring dimensions; the monitoring dimensions include the transmission channel status, module operation status, and data transmission status. S302: Real-time acquisition of status parameters in various dimensions; among which, transmission channel parameters include transmission rate, bit error rate, transmission delay and channel occupancy rate, module operation parameters include CPU occupancy rate, memory usage rate, power supply voltage and operating temperature, and data transmission parameters include data integrity, whether data is lost and serial number continuity; S303: Preset safety thresholds for each state parameter, compare real-time collected data with the thresholds to determine whether there is an abnormal state; S304: Perform hierarchical fault tolerance processing for different anomaly types; switch to backup channel and update scheduling instructions when channel is abnormal; enable redundant sub-module and reconstruct transmission link when module fails; trigger retransmission mechanism within preset time window when data is lost.

[0040] In the above process, a multi-dimensional status monitoring matrix is ​​constructed using a communication scheduling module, defining three core monitoring dimensions: transmission channel status, module operation status, and data transmission status. Specific monitoring indicators are defined for each dimension, forming a comprehensive status monitoring system to ensure no monitoring blind spots and provide data support for subsequent anomaly detection and fault-tolerant handling. Specifically, transmission channel status focuses on link transmission performance, module operation status focuses on hardware stability, and data transmission status focuses on data integrity; these three aspects work together to achieve full-process status monitoring.

[0041] The communication scheduling module collects status parameters in real time at a 2ms acquisition cycle, ensuring the continuity and timeliness of parameter collection. Transmission channel parameters specifically include transmission rate (in Mbps, real-time statistics of link data transmission speed), bit error rate (the ratio of erroneous data to total transmitted data), transmission delay (the total time from data transmission to reception, accurate to milliseconds), and channel occupancy (the proportion of resources currently occupied by the channel, ranging from 0% to 100%). Module operation parameters specifically include CPU utilization (the resource utilization ratio of each module's core processor), memory utilization (the memory usage of each module), power supply voltage (the module's operating voltage, ensuring it remains within the rated voltage range), and operating temperature (the operating temperature of the module's core components, preventing overheating failures). Data transmission parameters specifically include data integrity (the consistency verification result between the received and transmitted data), data loss (determined by the continuity of data sequence numbers; interrupted sequence numbers indicate data loss), and sequence number continuity (assigning a unique sequence number to each transmitted data item and verifying its continuity). All collected parameters are entered into the status monitoring matrix in real time, dynamically updating the data.

[0042] Security thresholds for each status parameter are preset. These thresholds are pre-configured based on gateway hardware performance and business communication requirements and can be dynamically adjusted. Real-time collected parameters are compared one by one with the corresponding thresholds to determine if any abnormal states exist. For example, the bit error rate threshold for the transmission channel is set to 1%; exceeding this value indicates a channel abnormality. The transmission delay threshold matches the real-time performance level of the data; the delay threshold for high-real-time data is ≤10ms, exceeding this value indicates an abnormality. The module CPU utilization threshold is set to 80%; consistently exceeding this value indicates an operational abnormality. An interruption in the data sequence number is directly considered data loss. After comparison, the abnormal dimension, abnormal parameters, and abnormal severity are marked, providing a basis for tiered fault-tolerant processing.

[0043] Differentiated hierarchical fault-tolerant processing strategies are implemented for different anomaly types to quickly respond to anomalies and minimize their impact on communication. When a transmission channel anomaly is detected (bit error rate exceeding the limit, transmission delay exceeding the limit, or channel occupancy rate of 100% for 10ms), the communication scheduling module immediately selects the best-performing backup channel of the same type from the backup channel pool (prioritizing channels with the same bandwidth and transmission rate as the original channel), quickly switches the transmission link, updates the channel information in the scheduling command, and synchronously notifies the main control module and relevant protocol adaptation submodules. The link switching time is controlled within 5ms to ensure uninterrupted data transmission. When a module failure is detected (module unresponsive time exceeds 30ms, CPU occupancy rate is consistently >80%, or operating temperature exceeds the rated threshold), the main control module immediately instructs the activation of the corresponding protocol's redundant adaptation submodule (1-2 redundant submodules are configured for each protocol type and are in standby mode), and the communication scheduling module restarts... The newly planned transmission link migrates the transmission tasks of the faulty module to a redundant sub-module. Simultaneously, a reset and restart operation is performed on the faulty module. If the reset is successful, it becomes a backup module; if the reset fails, fault information (module number, fault type, and fault time) is recorded. When data loss is detected (serial number interruption or integrity verification failure), the main control module instructs the sending module to execute a data retransmission mechanism within a preset time window. The time window is dynamically set according to the data real-time level: ≤20ms for high-real-time data and ≤100ms for medium-low real-time data. The retransmission threshold is set to 3 times. If the retransmission is successful, data transmission is restored and the status is updated. If the retransmission fails after 3 attempts, fault details are recorded, and alarm information is sent to the cloud server and gateway management terminal to notify administrators for timely investigation and handling. Corresponding to the aforementioned embodiments of the IoT gateway multi-module communication method, this application also provides embodiments of the IoT gateway multi-module communication device.

[0044] Figure 5 This is a block diagram of a multi-module communication device for an Internet of Things (IoT) gateway, according to an exemplary embodiment. (Refer to...) Figure 5 The device may include: a communication demand identification and scheduling module 401, a data distribution module 402, and a communication state fault tolerance module 403; wherein: The communication demand identification and scheduling module 401 is used to collect multi-dimensional information, sort transmission requests based on hierarchical rules and generate scheduling instructions, and dynamically match transmission resources with communication demands. The data distribution module 402 is used to construct a priority queue for data distribution by combining communication rules and scheduling information, track progress in real time, and complete the target end encoding interaction. The communication state fault tolerance module 403 is used to monitor a multi-dimensional state construction matrix and execute a hierarchical fault tolerance strategy for channel anomalies, module failures, and data loss.

[0045] In this embodiment, the communication demand identification and scheduling module 401 collects multi-dimensional information, sorts transmission requests based on hierarchical rules, generates scheduling instructions, and dynamically matches transmission resources with communication demands. The data distribution module 402 combines communication rules and scheduling information to construct a priority queue for data distribution, tracks progress in real time, and completes target-end encoding interaction. The communication state fault tolerance module 403 monitors multi-dimensional states to construct a matrix and executes hierarchical fault tolerance strategies for channel anomalies, module failures, and data loss. Through the above methods, the adaptability of transmission protocols is improved, and data mistransmission and omission are avoided, thereby meeting the needs for efficient and reliable communication in complex scenarios.

[0046] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0047] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this application according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0048] Accordingly, this application also provides an electronic device, including: one or more processors; a memory for storing one or more programs; and when the one or more programs are executed by the one or more processors, causing the one or more processors to implement the multi-module communication method of the IoT gateway as described above. Figure 6 The diagram shown is a hardware structure diagram of any device with data processing capabilities, which is an IoT gateway multi-module communication device provided in an embodiment of the present invention. Except for... Figure 6 In addition to the processor, memory, and network interface shown, any data processing device in the embodiment may also include other hardware depending on the actual function of the data processing device, which will not be described in detail here.

[0049] Accordingly, this application also provides a computer-readable storage medium storing computer instructions thereon, which, when executed by a processor, implement the multi-module communication method of the IoT gateway as described above. The computer-readable storage medium can be an internal storage unit of any data-processing device as described in any of the foregoing embodiments, such as a hard disk or memory. The computer-readable storage medium can also be an external storage device, such as a plug-in hard disk, smart media card (SMC), SD card, flash card, etc., equipped on the device. Furthermore, the computer-readable storage medium can include both internal storage units of any data-processing device and external storage devices. The computer-readable storage medium is used to store the computer program and other programs and data required by the data-processing device, and can also be used to temporarily store data that has been output or will be output.

[0050] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the disclosure herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein.

[0051] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope.

Claims

1. A method for multi-module communication of an Internet of Things gateway, applied to an Internet of Things gateway comprising a heterogeneous network and a multi-protocol adaptation module, characterized in that, The method comprises the following steps: Collecting multi-dimensional information, sorting transmission requests based on hierarchical rules and generating scheduling instructions, and dynamically matching transmission resources and communication needs; Combined with communication rules and scheduling information, constructing a priority queue to distribute data, and real-time tracking progress and completing target end encoding interaction; Monitoring multi-dimensional state construction matrix, executing hierarchical fault tolerance strategy for channel abnormalities, module failures and data loss.

2. The IoT gateway multi-module communication method of claim 1, wherein, In the step of collecting multi-dimensional information, sorting transmission requests based on hierarchical rules and generating scheduling instructions, and dynamically matching transmission resources and communication needs: A communication scheduling module and each protocol adaptation submodule establish a real-time interaction link, and the connection state information of the submodules is collected; The connection state information includes connection stability, signal strength and access time length; Synchronously collecting data transmission request information of each submodule, obtaining request initiation time, key attributes such as whether it is an urgent request, and extracting core attributes of the data to be transmitted; The core attributes include protocol type, data size, real-time level and business importance label; Based on the hierarchical rules, a three-dimensional scheduling model is constructed, and the transmission requests are logically sorted according to the logic of core priority of real-time level, auxiliary adaptation of data size, and supplementary weighting of business importance.

3. The IoT gateway multi-module communication method of claim 2, wherein, After the step of constructing a three-dimensional scheduling model based on hierarchical rules and logically sorting transmission requests according to the logic of core priority of real-time level, auxiliary adaptation of data size, and supplementary weighting of business importance: Generate scheduling instructions containing channel number, timing plan and transmission sequence, complete dynamic matching of transmission resources and communication needs.

4. The IoT gateway multi-module communication method of claim 1, wherein, In the step of combining communication rules and scheduling information, constructing a priority queue to distribute data, and real-time tracking progress and completing target end encoding interaction: The main control module receives the uniformly formatted data output by the data transfer module, and extracts the target receiver identifier in the data; the target receiver identifier includes the target protocol adaptation submodule address and the cloud server IP; Retrieve the preset communication rules, divide the distribution path and transmission protocol requirements of different types of data, and send a distribution request to the communication scheduling module according to the channel allocation information in the scheduling instruction.

5. The IoT gateway multi-module communication method of claim 4, wherein, After the step of retrieving the preset communication rules, dividing the distribution path and transmission protocol requirements of different types of data, and sending a distribution request to the communication scheduling module according to the channel allocation information in the scheduling instruction: The communication scheduling module responds to the request, calls the corresponding transmission channel, and constructs a priority distribution queue.

6. The IoT gateway multi-module communication method of claim 5, wherein, After the step of using the communication scheduling module to respond to the request, calling the corresponding transmission channel, and constructing a priority distribution queue: According to the queue order, execute the data distribution operation, track the transmission progress in real time through the periodic feedback mechanism, synchronously feed back the distribution state to the main control module, and complete the encoding conversion and output to the heterogeneous device after the target end protocol adaptation submodule receives the data, complete the data interaction.

7. The IoT gateway multi-module communication method of claim 1, wherein, In the step of monitoring multi-dimensional state construction matrix, executing hierarchical fault tolerance strategy for channel abnormalities, module failures and data loss: The communication scheduling module constructs a multi-dimensional state monitoring matrix and clearly defines the monitoring dimensions; the monitoring dimensions include transmission channel state, module running state and data transmission state; Real-time acquisition of each dimension state parameter; wherein the transmission channel parameters include transmission rate, error rate, transmission delay and channel occupancy, the module running parameters include CPU occupancy, memory usage, power supply voltage and working temperature, the data transmission parameters include data integrity, whether lost and sequence number continuity; Pre-set safety threshold of each state parameter, compare real-time acquisition data with threshold, judge whether there is abnormal state; Carry out hierarchical fault-tolerant processing for different abnormal types.

8. The IoT gateway multi-module communication method of claim 7, wherein, In the step of carrying out hierarchical fault-tolerant processing for different abnormal types: Switch to standby channel and update scheduling instruction when channel is abnormal; When the module fails, enable redundant sub-module and reconfigure the transmission link; When data is lost, trigger the retransmission mechanism within the preset time window.

9. An IoT gateway multi-module communication apparatus employing the IoT gateway multi-module communication method according to claim 1, characterized by, It includes communication demand identification and scheduling module, data distribution module and communication state fault-tolerant module; wherein: The communication demand identification and scheduling module is used to collect multi-dimensional information, sort transmission requests based on hierarchical rules and generate scheduling instructions, and dynamically match transmission resources and communication demand; The data distribution module is used to combine communication rules and scheduling information to build priority queue to distribute data, track progress in real time and complete target end encoding interaction; The communication state fault-tolerant module is used to monitor multi-dimensional state to build matrix, and execute hierarchical fault-tolerant strategy for channel abnormality, module failure and data loss.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a computer program, the computer program includes program instructions, the program instructions make the processor execute the Internet of Things gateway multi-module communication method as claimed in any one of claims 1 to 8 when executed by the processor.

Images