Industrial Internet of Things gateway data transmission method and system supporting multi-protocol fusion

Abstract

The invention discloses an industrial Internet of Things gateway data transmission method and system supporting multi-protocol fusion, and relates to the technical field of data transmission, and the method comprises the steps: collecting data packets which are from different protocols and have the same process cycle identifier into a synchronous data group; calculating an intra-group predicted completion time range of the synchronous data group, and when the intra-group predicted completion time range exceeds an intra-group maximum allowable processing completion time difference predefined for the synchronous data group, marking a protocol processing channel where a data packet with the latest predicted completion time in the synchronous data group is located as an initial key protocol processing channel; according to the key channel identification and dynamic resource allocation method based on the intra-group predicted completion time range, the resource demand of the protocol processing channel can be accurately matched, the processing delay of the key channel is effectively shortened, and all data packets in the synchronous data group are ensured to be analyzed within the allowable time difference.

Description

Technical Field

[0001] This invention belongs to the field of data transmission technology, specifically an industrial IoT gateway data transmission method and system that supports multi-protocol fusion. Background Technology

[0002] In Industrial Internet of Things (IIoT) scenarios, collaborative operation of multiple devices often relies on data interaction using different communication protocols. These protocols differ significantly in transmission rate, data frame structure, and processing latency, making it difficult to synchronize and transmit related data within the same process cycle. Traditional industrial gateways often adopt a fixed resource allocation model, distributing equal computing resources to each protocol processing channel without considering the differences in processing time for data packets from different protocols. When a data processing delay occurs in a certain protocol channel, it can easily cause the completion times of data packets within a synchronized data group to be scattered, with the difference exceeding the allowable range.

[0003] This situation raises two core issues. First, asynchronously arriving data packets cannot be sent within the same time window according to the process logic sequence, which disrupts the timing consistency of data transmission and affects the collaborative control accuracy of downstream equipment. On the other hand, fixed resource allocation models lack dynamic adjustment capabilities, resulting in the inefficient use of idle resources. Meanwhile, heavily loaded protocol channels experience further delays due to resource shortages, creating a vicious cycle. Some existing multi-protocol gateways attempt to adapt to delayed data by extending the time window, but this reduces overall data transmission efficiency and fails to fundamentally address the mismatch between resource allocation and processing needs, making it difficult to meet the dual requirements of data synchronization and real-time performance in industrial scenarios. Summary of the Invention

[0004] The purpose of this invention is to provide an industrial IoT gateway data transmission method and system that supports multi-protocol convergence, so as to solve the problems mentioned in the background art.

[0005] Data transmission methods for industrial IoT gateways that support multi-protocol convergence include: Data packets from different protocols but with the same process cycle identifier are grouped into a synchronization data group; Calculate the range of expected completion times within the synchronization data group. When the range of expected completion times within the group exceeds the maximum allowable processing completion time difference predefined for the synchronization data group, mark the protocol processing channel where the latest data packet with the expected completion time in the synchronization data group is located as the initial critical protocol processing channel; temporarily allocate computing resources from the public dynamic resource pool established for the synchronization data group to the initial critical protocol processing channel. After all member data packets of the synchronization data group have completed protocol parsing, all data packets are continuously sent within a single time window according to the specified sending order within the group as required by the synchronization data group's process logic.

[0006] As a further aspect of the present invention: calculating the range of expected completion times within a synchronized data group, including: Get the remaining protocol parsing time for each data packet in the synchronization data group; Based on the remaining time for protocol parsing, predict the estimated completion time of each data packet; Calculate the difference between the latest expected completion time and the earliest expected completion time within the synchronized data group to obtain the range of expected completion times within the group.

[0007] As a further aspect of the present invention: determining that the range of expected completion times within a group exceeds the maximum allowable processing completion time difference within the group, specifically: The group is finally determined to have exceeded the maximum allowable processing completion time difference if and only if the range of the expected completion time within the group continuously exceeds the maximum allowable processing completion time difference within the group for at least one preset stabilization period.

[0008] As a further aspect of the present invention: the temporary allocation of computing resources includes: The urgency level of resource allocation is determined based on the ratio of the expected completion time range within the group to the maximum allowable processing completion time difference within the group. The basic allocation ratio is determined based on the urgency level and the protocol type of the initial critical protocol processing channel; The basic allocation ratio is dynamically adjusted based on the current overall computing resource utilization of the gateway to obtain the final allocation ratio; Calculate the amount of resources to be allocated based on the final allocation ratio. When the overall computing resource utilization of the gateway exceeds a preset threshold, the amount of resources is allocated in a phased and gradual manner. Perform resource allocation operations.

[0009] As a further aspect of the present invention: performing a resource allocation operation includes: Query the resource borrowing strategy table pre-configured based on experimental data, and determine the type and base quantity of resources to be borrowed based on the protocol type of the initial key protocol processing channel and the resource allocation level determined based on the expected completion time range within the group; resource types include CPU time slices, cache space or dedicated hardware accelerator time slots; Send a resource freeze request to the target non-critical protocol processing channel. The resource freeze request includes the type and quantity of resources to be frozen and the maximum freeze duration. After receiving the resource freeze confirmation response from the target non-critical protocol processing channel, mark the frozen resources as being in a lending state and transfer the scheduling authority of the frozen resources to the initial critical protocol processing channel. Once the initial critical protocol processing channel is used up or the maximum freeze duration is reached, the resource return process is triggered to clear the lending status and return the scheduling authority to the original channel.

[0010] As a further aspect of the present invention: determining the target non-critical protocol processing channel, including: Obtain the current load status of all candidate non-critical protocol processing channels and the criticality label of the data streams being processed; Exclude channels whose load exceeds a high threshold or whose criticality labels for the processed data streams are security-related. Among the remaining channels, the channel with the highest hardware resource topology sharing with the initial critical protocol processing channel and the least expected impact of resource borrowing on the channel's own timing assessment is selected as the target non-critical protocol processing channel.

[0011] As a further aspect of the present invention: continuously sending all data packets within a single time window, including: The parsed data packets within the group are placed into a dedicated sending buffer queue according to the specified sending order within the group; Start a group send synchronization timer. The duration of the group send synchronization timer is less than the maximum allowed processing completion time difference within the group. Before the group transmission synchronization timer expires, all data packets are continuously transmitted in the order of the transmission buffer queue, with the transmission interval being less than the interval of a single network frame. If all data packets are not sent before the group transmission synchronization timer expires, the group synchronization transmission status of subsequent data packets will be immediately cancelled, and the subsequent data packets will be downgraded to ordinary data packets and sent according to the default policy.

[0012] As a further aspect of the present invention, the method also includes: The gateway records the group sequence number of the failed synchronization data group and marks all unsuccessfully sent data packets in the failed synchronization data group with a synchronization failure mark. The gateway moves packets with a synchronization failure flag from the group send queue to a dedicated asynchronous retransmission queue; In the next transmission scheduling cycle, the gateway first checks the asynchronous retransmission queue and retransmits the data packets in the asynchronous retransmission queue in the form of unicast ordinary data packets, while carrying the group sequence number of the failed synchronization data group in the user data field of the data packet.

[0013] As a further aspect of the present invention, the method also includes: Before sending, a shared group sequence number and intra-packet sequence number are written to all member data packets of the synchronization data group, and a group synchronization identifier is marked in the network layer header of the data packet. The downstream system performs coordinated reception processing on data packets of the same group based on the group synchronization identifier and group sequence number.

[0014] Secondly, this application provides an industrial IoT gateway data transmission system supporting multi-protocol convergence, the system comprising: The classification module groups data packets from different protocols that have the same process cycle identifier into synchronization data groups; The calculation module calculates the range of expected completion times within the synchronization data group. When the range of expected completion times within the group exceeds the maximum allowable processing completion time difference predefined for the synchronization data group, the protocol processing channel where the latest data packet with the expected completion time in the synchronization data group is located is marked as the initial critical protocol processing channel. The module also temporarily allocates computing resources from the public dynamic resource pool established for the synchronization data group to the initial critical protocol processing channel. After the protocol parsing of all member data packets in the synchronization data group is completed, the sending module continuously sends all data packets within a single time window according to the specified sending order within the group as required by the process logic of the synchronization data group.

[0015] Compared with the prior art, the beneficial effects of the present invention are: This invention solves the problem of synchronous grouping of multi-protocol data by aggregating data packets with the same process cycle identifier, laying the foundation for subsequent orderly transmission. Based on the critical channel identification and dynamic resource allocation mechanism with a wide range of expected completion times within the group, it can accurately match the resource requirements of protocol processing channels, effectively shorten the processing delay of critical channels, and ensure that all data packets within the synchronous data group are parsed within the allowable time difference, avoiding resource waste and processing bottlenecks caused by fixed resource allocation. The logic for determining the proportion and quantity of newly added resources in the temporary allocation calculation process, along with the phased and gradual allocation strategy, enables refined control of resource allocation. This ensures that the initial critical protocol processing channels receive sufficient resource support while avoiding excessive overall gateway load. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of the method framework structure of the present invention. Detailed Implementation

[0017] The technical solution of the present invention will be clearly and completely described below with reference to the embodiments. 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] First aspect: Please refer to Figure 1 This application provides a data transmission method for industrial IoT gateways that supports multi-protocol fusion, including: Data packets from different protocols but with the same process cycle identifier are grouped into a synchronization data group; It should be noted that the supported protocol types cover commonly used industrial protocols such as Modbus, Profinet, EtherNet / IP, and MQTT. The process cycle identifier is generated by the gateway during the data access phase based on the process configuration of the upstream equipment. It adopts a 64-bit identifier field, which includes information such as equipment number, process segment code, and cycle number, to ensure that related data within the same process cycle can be accurately identified.

[0019] It should be understood that the following instructions are provided regarding the setting of the maximum allowable processing completion time difference within a group: The maximum allowable processing completion time difference within a group is a predefined parameter based on the collaborative processing needs of downstream systems. Its setting is primarily based on: Downstream equipment process synchronization window: determined based on the time tolerance that downstream controllers or actuators can effectively process related data within the same process cycle.

[0020] Network transmission jitter limit: Taking into account the inherent jitter of network transmission between the gateway and the downstream system, it ensures that after the data packets in the group are parsed within the allowed time difference, there is still a high probability that they will be delivered continuously within a single time window.

[0021] Gateway processing capacity baseline: Based on the typical processing performance of the gateway, set a reasonable threshold that can ensure synchronization without causing frequent resource rescheduling and excessive system load due to overly stringent requirements.

[0022] This parameter can be set and adjusted by engineers through the configuration interface during gateway deployment, based on specific industrial scenarios and process requirements; To provide deployment guidance, the recommended value range for this parameter in typical industrial scenarios is as follows: For high-speed real-time control scenarios (such as servo motion synchronization), a value of 5-10 milliseconds is recommended; for general process control scenarios (such as data exchange between PLCs), a value of 10-30 milliseconds is recommended; and for data acquisition and monitoring scenarios, a value of 30-50 milliseconds is recommended. The dynamic resource scheduling mechanism of this invention aims to ensure that, within the above recommended range, the difference in the final completion time of synchronized data groups can be compressed to less than 50% of this set value.

[0023] Furthermore, the specific method for obtaining the process cycle identifier may include any of the following: (1) Protocol Embedded Extraction: The gateway parses the timestamp, cycle counter or transaction identifier fields in a specific industrial protocol frame and maps them to a unified process cycle identifier.

[0024] (2) Upper computer configuration distribution: The upper computer management system distributes the process cycle identifier and corresponding relationship table to the gateway through independent configuration messages or management channels according to the production schedule.

[0025] (3) Automatic rule generation: The gateway automatically generates and assigns process cycle identifiers based on the pre-configured rules and the internal clock.

[0026] Those skilled in the art can select or combine the above methods to implement the solution based on the actual industrial network topology and management model.

[0027] Specifically, the 64-bit field of the process cycle identifier is allocated as follows: 16 bits for the equipment number, 8 bits for the process segment code, 32 bits for the cycle sequence number, and 8 bits for the check bit. The check bit is generated by XORing the binary values ​​of the equipment number, process segment code, and cycle sequence number to ensure the uniqueness of the identifier. The gateway has a built-in protocol parsing front-end module that identifies the protocol type and extracts the identifier from the received data packets. A hash mapping algorithm maps data packets with the same process cycle identifier to the same buffer queue, forming a synchronized data group. This step achieves accurate grouping of multi-protocol data through unified identifiers and hash mapping, avoiding confusion between data from different process cycles and improving data collection efficiency.

[0028] Understandably, the hash mapping algorithm uses SHA-256, and the last 16 bits of the hash value are used as the index for the cache queue, with the index collision rate controlled within 0.1%. The number of data packets in each synchronization data group can be configured according to actual process requirements, ranging from 2 to 16. The cache queue adopts a first-in, first-out storage strategy to avoid data sorting disorder.

[0029] Calculate the range of expected completion times within a synchronization data group, including: obtaining the remaining protocol parsing time for each data packet within the synchronization data group; Based on the remaining time for protocol parsing, predict the estimated completion time of each data packet; Calculate the difference between the latest expected completion time and the earliest expected completion time within the synchronized data group to obtain the range of expected completion times within the group; It should be noted that the remaining time for protocol parsing is obtained by relying on the gateway's real-time monitoring module. This module tracks the current parsing progress of each protocol processing channel, calculates the percentage of unprocessed portion based on the number of bytes in the data packet, and combines this with the historical average parsing rate of the channel to calculate the remaining time for protocol parsing of a single data packet.

[0030] It should be understood that the calculation formula is: Remaining protocol parsing time = Number of unprocessed bytes ÷ Channel historical average parsing rate. The channel's historical average parsing rate is updated on a rolling basis in groups of 100 packets, with an update cycle of 1 second. The initial value of this rate is loaded from a preset baseline rate table (e.g., Modbus: 1000 bytes / millisecond) based on the protocol type when the channel starts up, ensuring that the rate data matches the current channel operating status. This rolling rate calculation method dynamically adapts to changes in channel load, improving the accuracy of remaining time calculation.

[0031] It should be understood that the estimated completion time of each data packet is the sum of the current system time and the remaining time for protocol parsing. The system time is provided by the gateway's built-in high-precision real-time clock, with a time accuracy down to the microsecond level, avoiding interference from time errors on the estimated results. The gateway iterates through and sorts the estimated completion times of all data packets within the synchronization data group, selecting the maximum value as the latest estimated completion time and the minimum value as the earliest estimated completion time. The difference between the two is the range of estimated completion times within the group.

[0032] The determination that the range of expected completion times within a group exceeds the maximum allowable processing completion time difference within the group is made only when the range of expected completion times within a group continuously exceeds the maximum allowable processing completion time difference within the group for at least one preset determination stabilization period.

[0033] Specifically, the duration of the stabilization period is configured according to the real-time requirements of the industrial scenario, ranging from 1 to 5 milliseconds. For high-speed precision machining scenarios, it can be configured to 1 millisecond, and for ordinary monitoring scenarios, it can be configured to 3 milliseconds. The purpose of introducing a stabilization period instead of instantaneous determination is to filter out brief exceedances in range caused by instantaneous system load fluctuations or sudden changes in the difficulty of parsing a single data packet. This avoids unnecessary resource scheduling operations that may incur additional overhead, thereby improving the stability and efficiency of the overall system decision-making.

[0034] The gateway's built-in periodic monitoring module continuously samples the relationship between the range of expected completion times within a group and the maximum allowable processing completion time difference within the group at 0.5 millisecond intervals. When the continuous sampling results all meet the condition that the range exceeds the maximum allowable time difference, and the duration reaches the preset judgment stabilization period, the final judgment result is triggered, avoiding misjudgments caused by instantaneous data fluctuations. The design of the judgment stabilization period effectively filters instantaneous data fluctuations, reduces the misjudgment rate of critical channels, and improves the reliability of resource scheduling decisions.

[0035] When the range of expected completion times within a group exceeds the maximum allowable processing completion time difference predefined for the synchronization data group, the protocol processing channel containing the data packet with the latest expected completion time within the synchronization data group will be marked as the initial critical protocol processing channel. The above markings represent decisions based on the current computation time. The gateway's resource scheduler continuously recalculates the estimated completion time and intra-group range of each data packet within the synchronization data group at fixed intervals (e.g., 1 millisecond).

[0036] If, after resource allocation, changes in the data processing progress of different groups result in a new data packet being the one with the latest expected completion time, the system will automatically update the critical channel marker to the protocol processing channel where that data packet resides in the next scheduling cycle and adjust the resource scheduling strategy accordingly. This mechanism ensures that resource assistance is always accurately targeted at the current real-time bottleneck within the group.

[0037] Temporarily allocate computing resources from the public dynamic resource pool established for the synchronization data group to the initial critical protocol processing channel; Fundamentals of resource allocation: The composition and management rules of dynamic resource pools; The system allocates a fixed amount of basic resources to each protocol processing channel to ensure its most basic operation.

[0038] In addition, all temporarily unused resources of all channels, as well as the total remaining resources of the system, are centrally managed to form a common "dynamic resource pool". Logically, this resource pool can be regarded as a public resource library that serves the resource scheduling needs of all synchronous data groups. Its establishment is reflected in the fact that the system can apply for and allocate resources from this global pool when processing any synchronous data group.

[0039] When a channel is marked as a critical channel and requires additional resources, the scheduler does not forcibly take resources from the base resources of other channels, but instead allocates them from this common dynamic resource pool.

[0040] It should be understood that the resources in this pool are divided into standard small portions called "resource units." For example, one CPU resource unit represents the total computing power of a single CPU core within 1 millisecond. The system maintains a list of all currently available resource units.

[0041] Each non-critical protocol processing channel has a "lending limit," which is a certain percentage (e.g., 50%) of its own underlying resources. This means that the channel can contribute up to half of its underlying resources to the dynamic resource pool for other critical channels to borrow.

[0042] The resource borrowing process is as follows: 1. Lending: The scheduler retrieves the required number of resource units from the available unit list in the dynamic resource pool and marks them as "lent out". At the same time, the corresponding number of units are deducted from the "available lending quota" in the lending channel.

[0043] 2. Use: Temporarily transfer the use rights of these borrowed resource units to the critical channel.

[0044] 3. Return: When the critical channel runs out of resources or the borrowing period expires, the resource unit is marked as "available" and returned to the dynamic resource pool list. At the same time, the "available lending quota" deducted from the lending channel is restored.

[0045] In this way, the critical channel can receive additional assistance, while the basic resources required for the lending channel to operate remain intact and unaffected, achieving safe and flexible resource allocation.

[0046] Temporary allocation of computing resources includes: determining the proportion and quantity of computing resources to be allocated based on the expected completion time range within the group and the current overall computing resource utilization rate of the gateway; When the overall utilization rate exceeds the threshold, a phased and gradual allocation strategy is adopted. Identify the target non-critical protocol processing channels; Perform resource allocation operations; It should be noted that the proportion and quantity of computing resources to be allocated are determined through the following specific steps: Calculate the urgency level: Urgency Level = Ceil(range of estimated completion time within the group / maximum allowable processing completion time difference within the group). Ceil() is a rounding function. The result corresponds to levels 1 to 5; if the result is greater than 5, it is processed as level 5.

[0047] Determine the basic allocation ratio: Based on the urgency level calculated in the previous step and the protocol type of the initial critical protocol processing channel, refer to the table below to obtain a reference value for the basic allocation ratio. The ratio values ​​in this table are determined based on the following principles and through benchmark testing: the higher the urgency level, the greater the proportion of additional resources needed to catch up on latency; The more complex the protocol processing or the longer the baseline latency (e.g., EtherNet / IP compared to Modbus), the higher the utilization rate of additional resources for its processing tasks, and therefore the slightly higher allocation ratio at the same level. This table shows the baseline configuration preset by the gateway at the factory; , Dynamically adjust based on system load: The gateway monitors the overall computing resource utilization in real time. The system presets a safe threshold for overall utilization (e.g., 75%). If the current overall utilization is lower than or equal to this threshold, it indicates that the system resources are sufficient, and the basic allocation ratio obtained from the table above can be directly used. If the current overall utilization is higher than this threshold, it indicates that the system is under high load, and to avoid exacerbating the system burden due to resource reallocation, the allocation ratio needs to be reduced.

[0048] The reduction method is as follows: The system maintains a load-reduction factor lookup table. The purpose of this table is to reduce the proportion of resources allocated to critical channels according to rules when the overall system load is high, in order to prevent system overload.

[0049] Specifically, the rules for constructing and using this table are as follows: Set a safety threshold, for example, 75%. When the overall system utilization does not exceed this threshold, the reduction will not be initiated, and the reduction factor will be 1.0.

[0050] Set the interval step size and decay value: Starting from the safety threshold, the system utilization rate enters the next higher load interval every time it exceeds a fixed "step size" (e.g., 5%). Each time the system enters the next higher load interval, the reduction factor is reduced by a fixed "decay value" (e.g., 0.1) based on the coefficient of the previous interval.

[0051] Set a minimum coefficient: To prevent over-allocation, set a minimum value for the reduction coefficient (e.g., 0.5).

[0052] Example of a query representation generated based on the above rules: Assume a safety threshold of 75%, a step size of 5%, a decay value of 0.1, and a minimum coefficient of 0.5.

[0053] Utilization rate ≤ 75%: Reduction factor = 1.0; 75% < utilization rate ≤ 80%: reduction factor = 1.0 - 0.1 = 0.9; 80% < utilization rate ≤ 85%: reduction factor = 0.9 - 0.1 = 0.8; 85% < utilization rate ≤ 90%: reduction factor = 0.8 - 0.1 = 0.7; 90% < utilization rate ≤ 95%: reduction factor = 0.7 - 0.1 = 0.6; Utilization rate > 95%: reduction factor = 0.5 (minimum value already reached).

[0054] The safety threshold, step size, decay value, and minimum coefficient are configurable parameters. However, the core lookup table rule—starting from the threshold, dividing intervals with a fixed step size, and decreasing the coefficient by a fixed amount for each interval until the minimum value—is fixed and publicly known. Those skilled in the art can configure or generate their own lookup tables based on this rule.

[0055] The system determines the corresponding reduction factor based on the current overall utilization range. The core principle of this dynamic reduction mechanism is that when the overall system load is high, large-scale resource reallocation operations may cause scheduling overhead and performance fluctuations. Therefore, it is necessary to appropriately suppress the resource allocation to a single critical channel to maintain the overall stability of the gateway's processing. The base allocation ratio is multiplied by this factor to obtain the final, load-adjusted allocation ratio. The final allocation ratio has an upper limit (e.g., 80%) to prevent a single channel from consuming excessive resources.

[0056] Calculate the number of resources: The final number of resources to be allocated is the product of the final allocation ratio and the static resource quota of the initial critical protocol processing channel. For example, if the static CPU quota of a Profinet channel is 20% and the final allocation ratio is 20%, then it is necessary to temporarily increase its CPU time slices by 20% × 20% = 4%.

[0057] When the overall utilization rate does not exceed the threshold, a one-time full allocation strategy is adopted to directly allocate the resource proportion and quantity determined according to the above steps to the initial critical protocol processing channel. When the overall utilization exceeds the threshold, a phased, incremental allocation strategy is adopted. This strategy is to avoid sudden changes in system scheduling load caused by injecting a large amount of additional resources at once, which could lead to processing latency fluctuations or brief pauses. In practice: Allocation strategy: The number of allocations and the proportion per allocation are dynamically determined based on the overall system utilization rate. When the overall system utilization rate is ≤75%: Number of allocations: 3; Single allocation percentage: 33% of the total resources required each time; When the overall system utilization rate is >75%: Number of allocations: 5; Single allocation percentage: 20% of the total required resources for each allocation.

[0058] Allocation Interval: A 1-millisecond time interval is set between each allocation. This interval is slightly longer than the system's core scheduling cycle to ensure that after receiving a batch of new resources, the system has enough time to complete task rescheduling and load balancing, and the next allocation will only proceed after the state stabilizes.

[0059] Strategic Advantages: The above parameter combination aims to ensure a smooth transfer of resources to critical channels while minimizing the additional system overhead caused by resource scheduling operations themselves. When system load is low, fewer allocations with a larger proportion are used to quickly meet the needs of critical channels; when system load is high, more allocations with a smaller proportion are used to minimize the impact on the overall system.

[0060] Identify the target non-critical protocol processing channel, including: obtaining the current load status of all candidate non-critical protocol processing channels and the criticality labels of the data streams they process; Exclude channels whose load exceeds a high threshold or whose criticality labels for the processed data streams are security-related. Among the remaining channels, the channel with the highest hardware resource topology sharing with the initial critical protocol processing channel and the least expected impact of resource borrowing on the channel's own timing assessment is selected as the target non-critical protocol processing channel.

[0061] It should be noted that the current load status of the candidate non-critical protocol processing channel is collected in real time by the resource monitoring module. The collected indicators include the current CPU utilization rate, memory utilization rate, and unprocessed data packet queue length of the channel. The comprehensive load value of the channel is calculated by weighting the three, with the weight allocation as follows: CPU utilization rate 0.4, memory utilization rate 0.3, and queue length 0.3.

[0062] Specifically, the high load threshold is set based on the channel's basic resource quota, and the configuration range is 70%-85% of the basic resource quota. For example, if the Modbus protocol channel has a basic CPU quota of 15%, its high load threshold is 10.5%-12.75%.

[0063] It should be understood that data flow criticality labels are generated by the gateway during the data access phase based on the process configuration of upstream equipment. These labels are divided into three levels: "Safety Related," "Control Related," and "Monitoring Related." The "Safety Related" label applies to core data flows involving equipment safety interlocks and emergency shutdowns (such as shutdown command data flows sent by safety PLCs), and resources for these channels are prohibited from being lent out. The "Control Related" label applies to equipment collaborative control data flows, and the "Monitoring Related" label applies to data acquisition and monitoring data flows; the latter two are candidate channels for resource lending. This criticality label grading mechanism can mitigate the risk of resource misappropriation for safety-related data flows, ensuring industrial production safety.

[0064] Specifically, hardware resource topology sharing is evaluated through the resource topology table built into the gateway. The sharing indicators include whether they share the same CPU core, whether they share the same cache pool, and whether they share the same memory controller. Each indicator is worth 1 point, with a maximum score of 3 points. The higher the score, the stronger the sharing (e.g., a channel that shares the same CPU core and cache pool as the initial critical protocol channel is worth 2 points).

[0065] Assessing the impact of resource borrowing on non-critical channels: The system will estimate the potential impact on the data processing timing of a candidate non-critical channel after borrowing resources from that channel. The assessment primarily considers two factors: Resource borrowing ratio: This calculates the proportion of planned resource borrowing to the total available idle resources of the channel. The total idle resources here refer to the resources remaining after ensuring the smooth operation of the channel's current tasks, not its entire base quota. The smaller the borrowing ratio, the smaller the potential impact on the channel.

[0066] Historical stability of the channel: Examine the fluctuations in processing time over a past period (e.g., during the processing of the last 100 packets). If its processing time is very stable (small fluctuations), it indicates that its tolerance for external interference (such as resource borrowing) may be low, and the impact assessment value of resource borrowing will be increased; conversely, if its processing time already has some fluctuations (large fluctuations), it indicates that it may be more affected by other factors, and the additional impact of resource borrowing may be relatively smaller, and the assessment value will be lowered.

[0067] The system combines the aforementioned resource borrowing ratio with a channel sensitivity coefficient calculated based on historical stability to arrive at a comprehensive impact assessment value. A candidate channel with a lower impact assessment value indicates that borrowing resources from it will cause minimal disruption to its normal operation, and therefore has a higher priority.

[0068] The target channel is ultimately selected based on a priority order of descending sharing score and ascending impact value. If multiple channels are tied, the channel with the largest total amount of idle resources is selected. This dual-channel selection criterion of sharing and impact value maximizes resource utilization efficiency while minimizing disruption to non-critical channels.

[0069] Query the resource borrowing strategy table pre-configured based on experimental data, and determine the type and base quantity of resources to be borrowed based on the protocol type of the initial key protocol processing channel and the resource allocation level determined based on the expected completion time range within the group.

[0070] The resource borrowing strategy table is constructed as follows: The resource borrowing strategy table specifies the types of resources to be borrowed and their baseline quantities for different protocol types and urgency levels in order to effectively reduce processing latency. The table is developed following explicit rules based on protocol processing characteristics and resource performance: Resource type selection rules: Complex protocols (such as Profinet, EtherNet / IP) are given priority in allocating dedicated hardware accelerator time slots and cache space; simple protocols (such as Modbus) are mainly allocated CPU time slices.

[0071] Rules for determining quantity benchmarks: The baseline proportion of CPU time slices is obtained by multiplying the protocol's base coefficient by the urgency level. Different protocols have different base coefficients.

[0072] The base size of the cache space (MB) is obtained by adding a base value to (the urgency level minus one) multiplied by an increment.

[0073] The base duration (in milliseconds) of a dedicated hardware accelerator session is obtained by multiplying the urgency level by a base duration coefficient.

[0074] Example of table content based on rules: The table below shows some exemplary data derived from the rules above. The complete table can be expanded according to these rules: , The gateway is pre-configured with a policy table generated according to this rule. The specific values ​​of the base coefficient, base value, incremental value, base duration coefficient, etc. in the rule can be adjusted near the example value during deployment based on the actual hardware performance of the gateway.

[0075] As an example, the base coefficient, base value, incremental value, and base duration coefficient can be configured as follows: Modbus protocol base coefficient 5%, base value 256MB, incremental value 128MB, and base duration coefficient 0.5 milliseconds; Profinet protocol base coefficient 3%, base value 512MB, incremental value 256MB, and base duration coefficient 1 millisecond.

[0076] Resource types include CPU time slices, cache space, or dedicated hardware accelerator time slots; Send a resource freeze request to the target non-critical protocol processing channel. The resource freeze request includes the type and quantity of resources to be frozen and the maximum freeze duration. After receiving the resource freeze confirmation response from the target non-critical protocol processing channel, mark the frozen resources as being in a lending state and transfer the scheduling authority of the frozen resources to the initial critical protocol processing channel. When the initial critical protocol processing channel is used up or the maximum freeze duration is reached, the resource return process is triggered to clear the lending status and return the scheduling authority to the original channel. It should be noted that the resource borrowing policy table is a static table entry pre-configured by the gateway. The table entry dimensions include the mapping relationship between protocol type, resource allocation level, resource type, and resource quantity. The resource allocation level is divided into 1-5 levels according to the ratio of the expected completion time range within the group to the maximum allowed time difference. The higher the level, the more resources are allocated. For example, when the Profinet protocol corresponds to level 3, the allocated resources are 10% of the CPU time slice and 512MB of cache space.

[0077] Specifically, dedicated hardware accelerator time slots are suitable for protocol parsing scenarios with high computing power requirements. For example, EtherNet / IP protocol parsing can utilize the FPGA accelerator time slots built into the gateway, with a single borrowing time not exceeding 5 milliseconds. Utilizing the resources of dedicated hardware accelerators can specifically improve the parsing efficiency of high-computing-power protocols and shorten processing time.

[0078] It should be understood that the maximum freeze duration is determined based on the resource type and the load of the initial critical protocol processing channel. The maximum freeze duration for CPU time slices is 5-10 milliseconds, the maximum freeze duration for cache space is 10-20 milliseconds, and the maximum freeze duration for dedicated hardware accelerator periods is 3-8 milliseconds. The maximum freeze duration must cover the expected remaining processing time of the initial critical protocol processing channel to avoid prematurely reclaiming resources and affecting the parsing progress.

[0079] Furthermore, upon receiving a resource freeze request, the target non-critical protocol processing channel must provide a confirmation response within 0.5 milliseconds. If the response time limit is exceeded, it will be considered a rejection, and the resource scheduling controller will automatically select another non-critical protocol processing channel to initiate the request.

[0080] Specifically, the transfer of resource scheduling authority is achieved by updating the gateway's resource scheduling table, modifying the channel identifier of the frozen resources to the initial critical protocol processing channel identifier, and recording the transfer time and the maximum freeze duration. The gateway's scheduler will then prioritize allocating these resources to the initial critical protocol processing channel in subsequent scheduling cycles.

[0081] The resource return process is triggered by either a resource release command actively sent by the initial critical protocol processing channel after completing packet parsing, or by automatic triggering by the gateway when the maximum freeze time is reached. During return, the resource's "lending" status is cleared first, and then the scheduling permission identifier is restored to the original non-critical protocol processing channel identifier. The entire return process has an execution delay of no more than 0.3 milliseconds, ensuring that resources in non-critical protocol processing channels are quickly restored to availability. This rapid resource return mechanism reduces the resource occupation time of non-critical channels, ensuring that their normal data processing is not affected in the long term.

[0082] After all member data packets of the synchronization data group have completed protocol parsing, all data packets are continuously sent within a single time window according to the specified sending order within the group as required by the process logic of the synchronization data group. Send all data packets continuously within a single time window, including: placing the parsed data packets within a group into a dedicated sending buffer queue in the specified group sending order; Start a group send synchronization timer. The duration of the group send synchronization timer is less than the maximum allowed processing completion time difference within the group. Before the group transmission synchronization timer expires, all data packets are sent continuously in the order of the transmission buffer queue, with a transmission interval less than the interval of a single network frame. If all transmissions are not completed before the group transmission synchronization timer expires, the group synchronization transmission status of subsequent data packets is immediately canceled, and subsequent data packets are downgraded to ordinary data packets and sent according to the default strategy.

[0083] It should be noted that the dedicated send buffer queue is a circular queue independently allocated by the gateway for each synchronization data group. The queue length is configured to be 1.2 times the maximum number of data packets in the synchronization data group (e.g., if the maximum is 16 data packets, the queue length is 20) to avoid queue overflow. The queue adopts a write-locking and continuous-read mechanism, and is only unlocked for reading after all data packets have been written, ensuring that the sending order is consistent with the preset order.

[0084] Independent circular queues and read-write locking mechanisms ensure that the order of data packet transmission strictly matches the process logic requirements, avoiding out-of-order transmission.

[0085] It should be understood that the duration of the group transmission synchronization timer is configured as a preset percentage of the maximum allowable processing completion time difference within the group, typically ranging from 50% to 80%. The purpose of this setting is to reserve sufficient time for the actual transmission of data packets within the maximum allowable time difference within the group, while simultaneously driving the gateway to prioritize and continuously transmit data within the group by setting a more pressing transmission deadline. This ensures that downstream systems can receive all associated data packets nearly synchronously within the tight timeframe required by the process cycle. For example, in a high-speed precision machining scenario with a maximum allowable time difference of 10 milliseconds, the timer duration can be configured to 5-8 milliseconds. For typical monitoring scenarios with a maximum permissible time difference of 50 milliseconds, the timer duration should be configured to 25-40 milliseconds. The single network frame interval is preset according to the industrial Ethernet type: 1 microsecond for EtherNet / IP protocol and 0.5 microsecond for Profinet protocol. The transmission interval must be strictly less than the corresponding protocol's single frame interval to ensure continuous and uninterrupted data packet transmission.

[0086] The transmission design with a shorter than frame interval enables seamless and continuous transmission of data packets, ensuring the timing consistency of collaborative control of industrial equipment.

[0087] Specifically, after the gateway initiates the group's synchronization timer, it sends packets one by one in the queue order through a dedicated sending thread. The sending thread has a higher priority than the ordinary data sending thread to ensure timely delivery. If the timer timeout detection module determines that a timeout has occurred and there are still unsent data packets, it immediately sends an interrupt command to the sending thread, marks the "synchronization group identifier" of the unsent data packets as invalid, and moves them into the ordinary data packet sending queue. The default strategy for sending ordinary data packets is to send them on a "first-come, first-served" basis, and they occupy the basic transmission bandwidth (with lower priority than new synchronization data groups). For example, if a synchronization data group contains 8 data packets, the first 5 are sent before the timer expires, and the last 3 are immediately downgraded to ordinary data packets to avoid data transmission delays throughout the entire process cycle due to waiting timeouts.

[0088] The timeout degradation strategy can avoid the impact of transmission delays in a single synchronization group on the overall transmission efficiency, balancing the reliability and flexibility of synchronous transmission.

[0089] Specifically, the amount of resources temporarily allocated is determined based on the load gap of the initial critical protocol processing channel. The load gap is the ratio of the current remaining processing tasks to the remaining processing time of the channel. The load gap is calculated using the formula Load gap = (total number of unprocessed data packets × average processing time per byte) ÷ remaining processing time. The average processing time per byte is preset according to the protocol type: 0.02 microseconds / byte for Modbus protocol and 0.01 microseconds / byte for Profinet protocol.

[0090] Specifically, the allocation ratio is 60%-80% of the load gap, ensuring that the pressure on critical channels can be quickly alleviated without affecting the basic processing capacity of other channels. Resource allocation is implemented through the gateway's resource scheduling controller, with a scheduling cycle of 1 millisecond. It can respond to load changes in real time. When the difference between the estimated completion time of the initial critical protocol processing channel and the earliest completion time in the group narrows to 50% of the maximum allowable processing completion time difference, the temporarily allocated resources begin to be gradually reclaimed. The resource reclamation rate is 10% of the allocated resources every 1 millisecond until the basic resource quota is restored.

[0091] It should be noted that the criteria for determining whether the protocol parsing is complete are that the data packet passes the integrity check and format standardization process. The integrity check uses the CRC32 algorithm, which generates a 32-bit check code based on the identifier, length, and content fields of the data packet. If the check code matches the check code at the end of the data packet, the packet is considered complete.

[0092] Standardization processes convert data packets from different protocols into a unified data frame structure, which includes fields such as data identifier, length, content, and checksum, making it easier for downstream devices to parse them uniformly.

[0093] The transmission order within a specified group is pre-configured by the process logic and can be set through the gateway's visual configuration interface. It supports sorting by multiple dimensions such as device priority, data importance, and transmission path length. A unified data frame structure reduces protocol adaptation costs for downstream devices and improves system compatibility.

[0094] Understandably, the configuration information is stored in the gateway's non-volatile memory and is not lost after power failure. The duration of a single time window is dynamically adjusted based on the total data volume of the synchronization data group and the transmission bandwidth. The time window duration is calculated using the formula: total number of bytes in the synchronization data group ÷ (transmission bandwidth × 80%). The result must fall within the range of 5-50 milliseconds; if it exceeds this range, the boundary value is taken. This ensures continuous data transmission within the bandwidth limit, avoiding increased transmission latency due to an excessively long window or data fragmentation due to an excessively short window. Dynamic time window calculation can adapt to different data volumes and bandwidth scenarios, balancing transmission efficiency and timing accuracy.

[0095] It should be understood that the start time of the time window is the moment when the last data packet in the synchronized data group is parsed. The gateway ensures the timing accuracy of the time window through the clock synchronization module, and the clock synchronization error does not exceed 1 millisecond.

[0096] Specifically, a flow control mechanism is employed during data transmission to monitor the bandwidth utilization of the transmission link in real time. When the utilization exceeds 90%, the transmission rate is appropriately reduced by 10% each time. Once the utilization drops below 70%, the normal rate is restored by 5% each time, ensuring the stability of data transmission. This tiered flow control strategy can smoothly adjust the link load and avoid data packet loss or delay caused by bandwidth congestion.

[0097] This method solves the problem of synchronous grouping of multi-protocol data by aggregating data packets with the same process cycle identifier, laying the foundation for subsequent orderly transmission. Based on the critical channel identification and dynamic resource allocation mechanism with a wide range of expected completion times within the group, it can accurately match the resource requirements of protocol processing channels, effectively shorten the processing delay of critical channels, and ensure that all data packets within the synchronous data group are parsed within the allowable time difference, avoiding resource waste and processing bottlenecks caused by fixed resource allocation. The logic for determining the proportion and quantity of newly added resources in the temporary allocation calculation process, along with the phased and gradual allocation strategy, enables refined control of resource allocation. This ensures that the initial critical protocol processing channels receive sufficient resource support while avoiding excessive overall gateway load.

[0098] The selection mechanism for non-critical protocol processing channels ensures that resource borrowing does not affect the normal operation of security-related data flows and high-load channels through multi-dimensional decision-making based on load screening, criticality exclusion, sharing, and impact assessment, while maximizing resource borrowing efficiency and minimizing timing interference to non-critical channels. The fine-grained control logic for continuously sending data packets within a single time window ensures the sending order through a dedicated buffer queue, limits the sending duration through a synchronization timer, and ensures timing consistency through continuous sending at short intervals. At the same time, a timeout degradation strategy is set to avoid the transmission delay of the entire synchronization data group due to the timeout of some data packets. It balances the flexibility and reliability of transmission while ensuring timing consistency.

[0099] In some embodiments of this application, the method further includes: The gateway records the group sequence number of the failed synchronization data group and marks all unsuccessfully sent data packets in the failed synchronization data group with a synchronization failure mark. In this embodiment, the group sequence number of the synchronization data group is bound to the process cycle identifier. It adopts a 64-bit field design and is consistent with the allocation of the process cycle identifier field. The gateway triggers the failure recording process by sending a timeout interrupt signal of the synchronization timer through the group. The group sequence number and failure timestamp are stored in the fault log module of the gateway. The timestamp accuracy is at the microsecond level.

[0100] Synchronization failure is marked by a 1-bit flag reserved in the header of the data packet. A flag value of 1 indicates synchronization failure, while a flag value of 0 indicates normal synchronization. This flag does not affect the parsing of the basic protocol of the data packet. Beneficial effects: The group sequence number is strongly bound to the process cycle identifier, which can directly associate the production process link to which the failed data packet belongs, enabling accurate traceability of fault data. The microsecond-level timestamp can pinpoint the moment the specific fault occurred, greatly shortening the fault investigation cycle.

[0101] Specifically, the lightweight design with a single flag bit eliminates the need for additional data packet structure expansion and does not affect the original protocol parsing logic, enabling rapid identification of failed data packets without increasing system overhead.

[0102] The gateway moves packets with a synchronization failure flag from the group send queue to a dedicated asynchronous retransmission queue; In this embodiment, the asynchronous retransmission queue is an independent priority queue. The queue length is configured to be twice the maximum number of data packets in the synchronous data group. For example, if the maximum number of data packets in the synchronous data group is 16, the queue length is 32. The first-in-first-out storage strategy is adopted, and the discard strategy is also supported when the queue is full, discarding the earliest data packet that entered the queue and has been retransmitted more than 3 times.

[0103] The migration operation is performed by the gateway's queue management thread. This thread completes the packet migration within 1 millisecond after receiving the synchronization failure flag. During the migration process, the original protocol format, data content, and standardized frame structure of the data packets are preserved, and only the queue ownership identifier is updated. The innovation of this step lies in the physical isolation between the independent asynchronous retransmission queue and the synchronous transmission queue, which completely avoids failed data packets from crowding out synchronous transmission resources, eliminates the problem of blocking the transmission of normal synchronous data groups, and ensures the timeliness of transmission of core industrial production data. The queue-full discard policy, combined with retransmission limit, automatically cleans up invalid retransmission data, preventing redundant data from occupying bandwidth and storage resources for extended periods and improving the overall efficiency of the gateway. A fast migration mechanism within 1 millisecond ensures that failed data packets are promptly removed from the synchronization queue, reducing interference with subsequent synchronization processes.

[0104] In the next transmission scheduling cycle, the gateway first checks the asynchronous retransmission queue and retransmits the data packets in the asynchronous retransmission queue in the form of unicast ordinary data packets, while carrying the group sequence number of the failed synchronization data group in the user data field of the data packet. In this embodiment, the sending scheduling period is consistent with the gateway resource scheduling period, which is set to 1 millisecond. At the beginning of each scheduling period, the gateway prioritizes scanning the asynchronous retransmission queue, and the scanning priority is higher than the ordinary data packet sending queue and the new synchronization data group sending queue. The unicast format uses the standard unicast address format of industrial Ethernet. The destination address is the physical address of the target device of the original synchronous data group. The transmission protocol is consistent with the original data packet, such as Modbus and Profinet protocols.

[0105] The user data field of the data packet reserves 8 bytes to carry the group sequence number, which is stored in the following order: 16 bits for the device number, 8 bits for the process segment code, 32 bits for the cycle number, and 8 bits for the check bit. The check bit is generated by XORing the first 56 bits of the group sequence number to ensure the accuracy of the group sequence number transmission.

[0106] When retransmitting, the flow control strategy of ordinary data packets is adopted. The rate adjustment step size is the same as that of ordinary data packets, and the maximum number of retransmissions is set to 3. The interval between each retransmission is 2 milliseconds. If the retransmission fails after exceeding the number of retransmissions, a fault log is recorded and the data packet is discarded. The beneficial effects of this step are as follows: the priority scanning mechanism of the asynchronous retransmission queue assigns a higher retransmission priority to failed data packets than to ordinary data, thereby improving the retransmission success rate and reducing the loss rate of industrial production data. The design of carrying a group sequence number in the user data field enables downstream devices to accurately identify the original synchronous data group to which the retransmitted data packet belongs, realizing the complete integration of discrete retransmitted data and original group data, ensuring data correlation and integrity, and meeting the needs of industrial scenarios for data traceability and batch processing; Furthermore, by using the original transmission protocol and unicast address format, no additional adaptation logic is required in downstream devices, reducing system deployment and maintenance costs. At the same time, it matches the flow control strategy of ordinary data packets, avoiding link bandwidth congestion caused by retransmission operations and ensuring the overall network transmission stability.

[0107] In this regard, this application further proposes that the method also includes: Before sending, a shared group sequence number and intra-packet sequence number are written to all member data packets of the synchronization data group, and a group synchronization identifier is marked in the network layer header of the data packet. In this embodiment, the group sequence number is completely consistent with the process cycle identifier of the synchronization data group. It adopts a 64-bit field design and is stored in the order of 16 bits of equipment number, 8 bits of process segment code, 32 bits of cycle sequence number, and 8 bits of check bit. The check bit is generated by XOR operation of the first 56 bits of binary value.

[0108] Specifically, the sequence number within the packet is an 8-bit field, incrementing from 1 according to the order in which the data packets are sent within the synchronization data group, supporting a maximum of 255 member data packets. The group synchronization identifier is a 1-bit flag reserved in the network layer header. When the flag is set to 1, it indicates that the data packet is a member of the synchronization data group; when it is set to 0, it indicates a normal data packet. This flag does not occupy additional bandwidth resources and does not affect the network layer forwarding logic of the data packet.

[0109] The innovation of this invention lies in the fact that the group sequence number is fully bound to the process cycle identifier, realizing the precise association between the synchronous data group and the production process. The 8-bit in-packet sequence number can meet the sorting requirements of large-scale synchronous data groups. The lightweight design of the 1-bit group synchronization identifier enables the rapid differentiation between synchronous data packets and ordinary data packets without increasing transmission overhead, laying the foundation for downstream collaborative processing.

[0110] The downstream system performs coordinated reception processing on data packets of the same group based on the group synchronization identifier and group sequence number; In this embodiment, when the network receiving module of the downstream system (such as an industrial controller or a data acquisition server) parses the data packets, it first detects the group synchronization flag in the network layer header. When the flag is 1, it extracts the group sequence number and the packet sequence number from the data packet and stores them according to the group sequence number through the built-in group data cache queue. Data packets with the same group sequence number are sorted and reassembled according to the packet sequence number.

[0111] Collaborative receiving and processing includes data integrity verification (checking whether the sequence numbers in the packets are consecutive), data timing calibration (adjusting the processing timing of received data synchronously based on the process cycle associated with the group sequence number), and batch parsing processing (integrating the same group of data and submitting it to the application layer in batches to reduce the number of parsing operations).

[0112] If a missing sequence number is detected within a packet, the downstream system generates a retransmission request using the group sequence number and sends it back to the gateway to trigger a targeted retransmission.

[0113] The beneficial effects are that, based on the collaborative reception mechanism of group synchronization identifier and group sequence number, it enables rapid classification and orderly reassembly of the same synchronized data group, ensuring the integrity and timing consistency of data reception. The batch parsing processing mode significantly reduces the parsing overhead of downstream systems, improves data processing efficiency, and targeted retransmission requests can accurately fill in missing data, avoiding bandwidth waste caused by retransmitting the entire group of data, thus meeting the dual requirements of real-time and reliable data transmission in industrial scenarios.

[0114] Secondly, this invention also proposes an industrial IoT gateway data transmission system supporting multi-protocol fusion, the system comprising: The classification module groups data packets from different protocols that have the same process cycle identifier into synchronization data groups; The calculation module calculates the range of expected completion times within the synchronization data group. When the range of expected completion times within the group exceeds the maximum allowable processing completion time difference predefined for the synchronization data group, the protocol processing channel where the latest data packet with the expected completion time in the synchronization data group is located is marked as the initial critical protocol processing channel. The module also temporarily allocates computing resources from the public dynamic resource pool established for the synchronization data group to the initial critical protocol processing channel. After the protocol parsing of all member data packets in the synchronization data group is completed, the sending module continuously sends all data packets within a single time window according to the specified sending order within the group as required by the process logic of the synchronization data group.

[0115] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A data transmission method for an industrial IoT gateway that supports multi-protocol fusion, characterized in that, include: Data packets from different protocols but with the same process cycle identifier are grouped into a synchronization data group; Calculate the range of expected completion times within the synchronization data group. When the range of expected completion times within the group exceeds the maximum allowable processing completion time difference predefined for the synchronization data group, mark the protocol processing channel where the latest data packet with the expected completion time in the synchronization data group is located as the initial critical protocol processing channel; temporarily allocate computing resources from the public dynamic resource pool established for the synchronization data group to the initial critical protocol processing channel. After all member data packets of the synchronization data group have completed protocol parsing, all data packets are continuously sent within a single time window according to the specified sending order within the group as required by the synchronization data group's process logic.

2. The industrial IoT gateway data transmission method supporting multi-protocol fusion according to claim 1, characterized in that, Calculate the range of expected completion times within a synchronized data set, including: Get the remaining protocol parsing time for each data packet in the synchronization data group; Based on the remaining time for protocol parsing, predict the estimated completion time of each data packet; Calculate the difference between the latest expected completion time and the earliest expected completion time within the synchronized data group to obtain the range of expected completion times within the group.

3. The industrial IoT gateway data transmission method supporting multi-protocol fusion according to claim 2, characterized in that, The determination is made when the range of expected completion times within a group exceeds the maximum allowable processing completion time difference within the group, specifically: The group is finally determined to have exceeded the maximum allowable processing completion time difference if and only if the range of the expected completion time within the group continuously exceeds the maximum allowable processing completion time difference within the group for at least one preset stabilization period.

4. The industrial IoT gateway data transmission method supporting multi-protocol fusion according to claim 1, characterized in that, The temporary allocated computing resources include: The urgency level of resource allocation is determined based on the ratio of the expected completion time range within the group to the maximum allowable processing completion time difference within the group. The basic allocation ratio is determined based on the urgency level and the protocol type of the initial critical protocol processing channel; The basic allocation ratio is dynamically adjusted based on the current overall computing resource utilization of the gateway to obtain the final allocation ratio; Calculate the amount of resources to be allocated based on the final allocation ratio. When the overall computing resource utilization of the gateway exceeds a preset threshold, the amount of resources is allocated in a phased and gradual manner. Perform resource allocation operations.

5. The industrial IoT gateway data transmission method supporting multi-protocol fusion according to claim 4, characterized in that, Performing resource allocation operations includes: Query the resource borrowing strategy table pre-configured based on experimental data, and determine the type and base quantity of resources to be borrowed based on the protocol type of the initial key protocol processing channel and the resource allocation level determined based on the expected completion time range within the group; resource types include CPU time slices, cache space or dedicated hardware accelerator time slots; Send a resource freeze request to the target non-critical protocol processing channel. The resource freeze request includes the type and quantity of resources to be frozen and the maximum freeze duration. After receiving the resource freeze confirmation response from the target non-critical protocol processing channel, mark the frozen resources as being in a lending state and transfer the scheduling authority of the frozen resources to the initial critical protocol processing channel. Once the initial critical protocol processing channel is used up or the maximum freeze duration is reached, the resource return process is triggered to clear the lending status and return the scheduling authority to the original channel.

6. The industrial IoT gateway data transmission method supporting multi-protocol fusion according to claim 5, characterized in that: Identify the target non-critical protocol processing channels, including: Obtain the current load status of all candidate non-critical protocol processing channels and the criticality label of the data streams being processed; Exclude channels whose load exceeds a high threshold or whose criticality labels for the processed data streams are security-related. Among the remaining channels, the channel with the highest hardware resource topology sharing with the initial critical protocol processing channel and the least expected impact of resource borrowing on the channel's own timing assessment is selected as the target non-critical protocol processing channel.

7. The industrial IoT gateway data transmission method supporting multi-protocol fusion according to claim 1, characterized in that, Send all data packets continuously within a single time window, including: The parsed data packets within the group are placed into a dedicated sending buffer queue according to the specified sending order within the group; Start a group send synchronization timer. The duration of the group send synchronization timer is less than the maximum allowed processing completion time difference within the group. Before the group transmission synchronization timer expires, all data packets are continuously transmitted in the order of the transmission buffer queue, with the transmission interval being less than the interval of a single network frame. If all data packets are not sent before the group transmission synchronization timer expires, the group synchronization transmission status of subsequent data packets will be immediately cancelled, and the subsequent data packets will be downgraded to ordinary data packets and sent according to the default policy.

8. The industrial IoT gateway data transmission method supporting multi-protocol fusion according to claim 1, characterized in that, The method also includes: The gateway records the group sequence number of the failed synchronization data group and marks all unsuccessfully sent data packets in the failed synchronization data group with a synchronization failure mark. The gateway moves packets with a synchronization failure flag from the group send queue to a dedicated asynchronous retransmission queue; In the next transmission scheduling cycle, the gateway first checks the asynchronous retransmission queue and retransmits the data packets in the asynchronous retransmission queue in the form of unicast ordinary data packets, while carrying the group sequence number of the failed synchronization data group in the user data field of the data packet.

9. The industrial IoT gateway data transmission method supporting multi-protocol fusion according to claim 7, characterized in that, The method also includes: Before sending, a shared group sequence number and intra-packet sequence number are written to all member data packets of the synchronization data group, and a group synchronization identifier is marked in the network layer header of the data packet. The downstream system performs coordinated reception processing on data packets of the same group based on the group synchronization identifier and group sequence number.

10. An industrial IoT gateway data transmission system supporting multi-protocol fusion, applicable to the industrial IoT gateway data transmission method supporting multi-protocol fusion as described in any one of claims 1 to 9, characterized in that, include: The classification module groups data packets from different protocols that have the same process cycle identifier into synchronization data groups; The calculation module calculates the range of expected completion times within the synchronization data group. When the range of expected completion times within the group exceeds the maximum allowable processing completion time difference within the group as predefined for the synchronization data group, the protocol processing channel where the latest data packet with the expected completion time in the synchronization data group is located is marked as the initial critical protocol processing channel. Temporarily allocate computing resources from the public dynamic resource pool established for the synchronization data group to the initial critical protocol processing channel; After the protocol parsing of all member data packets in the synchronization data group is completed, the sending module continuously sends all data packets within a single time window according to the specified sending order within the group as required by the process logic of the synchronization data group.

Images