MODBUS wireless 4G Internet of Things gateway and operation method

Abstract

The invention relates to a MODBUS wireless 4G Internet of Things gateway and an operation method, and relates to the technical field of Internet of Things, and the Internet of Things gateway comprises a bottom cover, a circuit board is installed in the bottom cover, a top cover is inserted into the top of the bottom cover, a cooling fan is installed in the bottom cover, a partition plate is installed on the top of the circuit board, and the partition plate is inserted into the top of the bottom cover. The cooling fan is arranged between the partition plate and the inner wall of the bottom cover, an air duct is further installed in the bottom cover, and heat conduction assemblies are installed in the bottom cover and the top cover. The heat dissipation fins I and the heat conduction plate I are mounted in the bottom cover to conduct heat, the partition plate is mounted at the top of the circuit board to divide the internal area into two parts, and the heat dissipation fan and the air duct drive internal air to circularly move, so that the heat conduction plate I and the heat conduction plate II are matched to discharge heat, and the heat dissipation efficiency is improved. Therefore, the heat dissipation effect is improved while the sealing performance of the gateway is not damaged, and the heat dissipation influence caused by dust, impurities and the like is reduced.

Description

Technical Field

[0001] This application relates to the field of Internet of Things (IoT) technology, and in particular to a MODBUS wireless 4G IoT gateway and its operation method. Background Technology

[0002] In industrial deployments characterized by high dust, high humidity, or restricted airflow, MODBUS wireless 4G IoT gateways are often installed in enclosed spaces, such as power distribution cabinets, outdoor protective enclosures, and inside electrical control boxes. During prolonged operation, these devices need to simultaneously handle high-load tasks such as data acquisition, protocol conversion, and 4G wireless transmission, leading to a significant increase in heat generation in the main control unit and RF communication module.

[0003] Traditional IoT devices often rely on fan cooling or open-shell convection to maintain thermal balance between the processor and communication modules. However, in these enclosed environments, airflow is obstructed, air-cooled structures easily accumulate dust and experience a sharp drop in efficiency, making it difficult to dissipate internal heat in a timely manner. For devices like MODBUS wireless 4G IoT gateways that integrate multi-functional modules, thermal management issues are even more prominent. If heat dissipation is inadequate, it can easily lead to frequent processor throttling, unstable 4G communication, MODBUS protocol processing delays, and even damage to internal circuits due to overheating.

[0004] Currently, most gateway products on the market lack effective heat dissipation and distributed cooling mechanisms in their structural design. They lack structured heat conduction designs such as heat pipes, metal heat exchangers, or shell-assisted heat conduction paths, causing heat to accumulate near the core chip and RF module, forming localized hotspots. Long-term operation will seriously affect equipment stability, causing frequent communication interruptions, decreased computing performance, accelerated hardware aging, and other problems, making it difficult to meet the actual needs of high reliability and high continuity in industrial environments.

[0005] Secondly, scheduling systems typically lack a structured task distribution design at the control level, with all read / write, refresh, and status synchronization requests in the data channel processed through the same entry point. This lack of task type separation leads to overlapping instruction streams, uncontrollable execution chains, repeated flushing of cached data, and no delayed status checks after writes, resulting in status jitter and chaotic responses. In scenarios with continuously increasing task volume, interface congestion becomes significant, and device acknowledgment delays are severe, making it difficult to meet the real-time requirements of high-frequency instruction scheduling.

[0006] Scheduling platforms with custom script or module reuse capabilities often lack preprocessing analysis of method chains or function calls, preventing the system from resolving dependency graph structures before scheduling. Nested calls and cross-references within tasks directly create hidden circular dependency paths, which, once triggered, can cause the scheduler to deadlock or enter a recursive execution process. Scheduled tasks may fail to exit normally, impacting the queuing logic of all subsequent tasks and triggering system-level exceptions.

[0007] At the control strategy level, a simple periodic polling synchronization method is used, with each device interface being repeatedly triggered, and status data being rewritten before it has stabilized. No refresh rate management mechanism is introduced, nor is path isolation and delay control implemented for post-write status readback. This results in discontinuous status signals in the control path, severe data read / write overlap, unpredictable device response behavior, and insufficient stability of the control chain.

[0008] Analysis of the gateway's thermal management capabilities and scheduling logic architecture reveals that the current system lacks a closed-loop structure in both physical adaptability and control chain design, making it difficult to support stable operation under multi-tasking, high-density, and demanding environments. This invention addresses these shortcomings by proposing a collaborative optimization scheme to resolve heat dissipation bottlenecks and logical risks in task scheduling under enclosed deployment conditions. This scheme constructs a highly reliable and controllable IoT execution platform from both structural and algorithmic perspectives. Summary of the Invention

[0009] The purpose of this application is to provide a MODBUS wireless 4G IoT gateway and its operation method, which solves the problems of low heat dissipation efficiency of IoT gateways in enclosed spaces and unstable task execution of scheduling systems.

[0010] Firstly, the MODBUS wireless 4G IoT gateway provided in this application adopts the following technical solution:

[0011] A MODBUS wireless 4G IoT gateway includes a bottom cover with a circuit board installed inside. A top cover is inserted into the top of the bottom cover, and the top and bottom covers are engaged to form a complete gateway housing. A cooling fan is installed inside the bottom cover to drive airflow. A partition is installed on the top of the circuit board, and the cooling fan is placed between the partition and the inner wall of the bottom cover. An air duct is also installed inside the bottom cover to divide the airflow. Both the bottom and top covers have heat-conducting components installed inside, and the heat-conducting components abut against each other.

[0012] Preferably, the air duct includes a housing, which is fixedly installed on the inner wall of the bottom cover. A baffle is installed on the front side of the housing, and the baffle separates the air inlet and air outlet at both ends of the housing.

[0013] Preferably, the heat-conducting component includes a heat-conducting plate one and a heat-conducting plate two. The heat-conducting plate one is fixed and penetrates the side wall of the bottom cover, and the heat-conducting plate two is fixed and penetrates the side wall of the top cover. A heat dissipation fin one is installed on the side of the heat-conducting plate one inside the bottom cover, and a heat dissipation fin two is installed on the side of the heat-conducting plate two outside the top cover.

[0014] Preferably, the first heat-conducting plate and the second heat-conducting plate abut against each other, and thermally conductive silicone grease is coated between the first heat-conducting plate and the second heat-conducting plate.

[0015] Secondly, the gateway data channel operation method provided in this application adopts the following technical solution: A gateway data channel operation method includes the following steps:

[0016] S1. Configure parameters for multiple data channels, including at least protocol type, device address, function code, communication port, and sampling period;

[0017] S2. Instantiate the data channels, each data channel including an initialization function, a periodic update function, a write function, a refresh function, and a read function;

[0018] S3. Start the timer to trigger the periodic update function according to the sampling period;

[0019] S4. Receive external requests, including read requests, write requests, or refresh requests, and add the requests to the request scheduler;

[0020] S5. Request the scheduler to schedule the execution of the function according to the preset priority rules, with the priority from high to low as refresh function, write function, and periodic update function;

[0021] S6. Classify and process the scheduling tasks, and perform the corresponding device access operations or data processing operations according to the function type.

[0022] Preferably, each of the data channels consists of a set of standard functions, which includes:

[0023] The initialization function is used to establish a communication connection with the device and initialize resources;

[0024] The periodic update function is used to collect device data according to a set period.

[0025] The write function is used to write control commands or set values ​​to the device;

[0026] The refresh function is used to request the status from the device and update the local cache immediately;

[0027] The read function is used to return the most recent valid data from the local cache.

[0028] Preferably, the request scheduler employs a priority-based sorting scheduling mechanism:

[0029] First, the priority is determined based on the request type. Refresh requests have a higher priority than write requests, and write requests have a higher priority than periodic update requests.

[0030] In the case of requests of the same type, they are sorted according to the order in which they arrived.

[0031] The sorted requests are scheduled and executed sequentially.

[0032] Preferably, before scheduling a task, the system constructs a call dependency graph between task functions. The nodes in this graph represent function entities, and the edges represent direct call relationships between functions. By performing a topological sort on this dependency graph, if a loop is detected, it is determined that there is a risk of recursion or deadlock, and the system suspends the execution of the task and issues an exception prompt.

[0033] Preferably, the timer triggers the periodic update function with a minimum granularity of one second, and satisfies the following conditions:

[0034] The scheduling system is modeled as a queuing system with a single service channel;

[0035] Within any given time period, the average arrival rate of tasks is lower than the scheduler's processing rate.

[0036] The average waiting time for each periodic update task is less than its corresponding set update cycle, so as to ensure that the periodic task can be completed within a limited time.

[0037] Preferably, the data channel includes a preset type channel and a programmable type channel:

[0038] The preset type channel is generated according to the system configuration file and the communication logic is constructed using a standard protocol structure;

[0039] The programmable type channel is defined by the user through scripts, specifying the execution logic of various functions.

[0040] When a programmable channel is set to exclusive execution mode, the system allocates a separate scheduler thread resource to it to isolate its running environment.

[0041] In summary, this application includes at least one of the following beneficial technical effects:

[0042] 1. This invention divides the gateway body into two sets of mutually fitting parts, and installs heat dissipation fins and heat conduction plates inside the bottom cover for heat conduction. A partition is installed on the top of the circuit board to divide the internal area into two parts. Then, the internal air is circulated by a cooling fan and air duct. This works in conjunction with heat conduction plates to dissipate heat, thereby improving the heat dissipation effect without compromising the gateway's airtightness and reducing the heat dissipation impact caused by dust and impurities.

[0043] 2. This invention employs a task classification and distribution mechanism and a function mapping and calling strategy to achieve modular processing and unified interface management of scheduling requests. Different types of tasks are assigned to corresponding modules for execution through mapping relationships, and read / write consistency is coordinated through a cache structure. Compared to the traditional approach of "unified entry point but no classification logic," this design effectively solves the problems of chaotic task distribution and untimely cache updates, improving the stability and logical clarity of data channel operations;

[0044] 3. This invention introduces function call graph construction and directed graph loop detection techniques to perform static analysis of dependency paths before scheduling tasks, thereby preventing potential deadlocks and recursion during the scheduling phase. Compared to some existing systems that only expose dependency errors at runtime and lack unified detection logic, this mechanism achieves "fault prevention before scheduling," avoiding system crashes caused by improper script design or excessively deep method nesting, and enhancing the scheduler's operational robustness and the controllability of task scheduling. Attached Figure Description

[0045] Figure 1 This is a perspective view of the present invention;

[0046] Figure 2 This is an exploded view of the structure of the present invention;

[0047] Figure 3 This is a schematic diagram of the partition installation position in this invention;

[0048] Figure 4 This is a schematic diagram of the air duct structure in this invention;

[0049] Figure 5 This is a schematic diagram of the operation steps of the data channel in this invention;

[0050] Explanation of reference numerals in the attached diagram: 1. Bottom cover; 2. Top cover; 3. Circuit board; 4. Air duct; 41. Housing; 42. Baffle; 43. Air inlet; 44. Air outlet; 5. Partition; 6. Cooling fan; 7. Heat conduction plate one; 8. Heat dissipation fin one; 9. Heat conduction plate two; 10. Heat dissipation fin two. Detailed Implementation

[0051] The following is in conjunction with the appendix Figure 1 -Appendix Figure 5 This application will be described in further detail below.

[0052] Example 1: A MODBUS wireless 4G IoT gateway, referring to... Figures 1-4The gateway includes a bottom cover 1, inside which a circuit board 3 is installed (the model of circuit board 3 in the attached diagram is for reference only). A top cover 2 is inserted into the top of the bottom cover 1. When the top cover 2 and the bottom cover 1 are engaged, they form a complete gateway housing. A cooling fan 6 is installed inside the bottom cover 1. The cooling fan 6 drives airflow to conduct heat away from the gateway. A partition 5 is installed on the top of the circuit board 3. The cooling fan 6 is placed between the partition 5 and the inner wall of the bottom cover 1. The partition 5 divides the internal space of the gateway into two parts: one part houses the internal components of the gateway, and the other part is used for heat conduction. After the top cover 2 is connected to the bottom cover 1, the top of the partition 5 fits snugly against the bottom of the top cover 2 to avoid airflow turbulence caused by incomplete space division. The bottom cover 1 is also equipped with an air duct 4 for dividing the airflow. The air duct 4 includes a housing 41, which is fixedly installed on the inner wall of the bottom cover 1. A baffle 42 is installed on the front side of the housing 41. The baffle 42 separates the air inlet 43 and the air outlet 44 at both ends of the housing 41. After installation, the baffle 5 is aligned with the air inlet 43. The air driven by the cooling fan 6 enters from the air inlet 43 and is then discharged from the air outlet 44 after being separated by multiple sets of housings 41, so as to facilitate the heat conduction inside the gateway.

[0053] Both the bottom cover 1 and the top cover 2 are equipped with heat-conducting components, which abut against each other. The heat-conducting components include a heat-conducting plate 7 and a heat-conducting plate 9. The heat-conducting plate 7 is fixed and penetrates the side wall of the bottom cover 1, and the heat-conducting plate 9 is fixed and penetrates the side wall of the top cover 2. A heat dissipation fin 8 is installed on the side of the heat-conducting plate 7 located inside the bottom cover 1, and a heat dissipation fin 10 is installed on the side of the heat-conducting plate 9 located outside the top cover 2. The heat-conducting plate 7 and the heat-conducting plate 9 abut against each other, and thermal grease is applied between the heat-conducting plate 7 and the heat-conducting plate 9. During air circulation, the heat generated during the operation of the components is carried away. When the air reaches the position of heat dissipation fin 18, the heat is conducted by heat dissipation fin 18 and conducted to the outside of the bottom cover 1 through heat conduction plate 17. Then, in conjunction with heat conduction plate 29, the heat is transferred to the position of heat dissipation fin 210 and discharged through external airflow. In this way, the heat dissipation effect can be improved without damaging the internal seal, and the impact of dust and debris interference caused by traditional fan cooling can be reduced.

[0054] The implementation principle of this application embodiment is as follows:

[0055] During assembly, first install the circuit board inside the bottom cover, then place the partition on the outside of the heat dissipation fin one, then install the air duct inside the bottom cover, making the air inlet fit against the partition, then insert the top cover from the outside of the bottom cover, and make the heat conduction plate two fit against the outside of the heat conduction plate one. During the assembly process, thermal grease can also be applied between the heat conduction plate one and the heat conduction plate two to improve the heat conduction effect. Then connect the top cover and the bottom cover with screws to complete the assembly of the entire gateway.

[0056] When the physical network gateway is working, the internal control unit of the circuit board drives the cooling fan to move the still air inside the gateway. After being guided by the baffle, the air enters the housing through the air inlet, passes through the cavity formed by the housing and baffle, and is finally discharged from the air outlet. The heat dissipation component consists of multiple sets of air ducts arranged in parallel, which can divide the incoming air into multiple groups. The air is blown smoothly by the arc-shaped design at the end of the housing, and is finally drawn back in from the input end of the cooling fan. This achieves air circulation inside the gateway. During the air circulation, the heat generated during the operation of the components is carried away. When the air reaches the first heat dissipation fin, the first heat dissipation fin conducts the heat, and then the heat is conducted to the outside of the bottom cover through the first heat conduction plate. Then, with the help of the second heat conduction plate, the heat is transferred to the second heat dissipation fin, and then the heat is discharged by the external airflow. This can improve the heat dissipation effect without compromising the internal sealing and reduce the interference of dust and debris caused by traditional fan cooling.

[0057] Example 2: A gateway data channel operation method, referring to... Figure 5 It includes the following steps:

[0058] S1. Configure parameters for multiple data channels, including at least protocol type, device address, function code, communication port, and sampling period;

[0059] In the data channel operation method of the MODBUS wireless 4G IoT gateway described in this invention, the configuration of the data channel is a key step in the system operation initialization phase, which is directly related to the correctness of the channel instance and the accuracy of task scheduling.

[0060] Typically, after system startup, users need to preset and configure parameters for several data channels based on specific application scenarios and device access requirements. The system provides channel types covering various industrial and general communication protocols, possessing strong protocol adaptability and scalability.

[0061] In step S1, the system mainly completes two types of operations: selecting the data channel type and configuring the channel operating parameters. This process lays the technical foundation for subsequent channel instantiation, scheduler orchestration, data transmission processing, and other stages.

[0062] In this embodiment, the user initiates a data channel addition operation through the configuration interface provided by the system.

[0063] The interface can be a graphical control panel or a remote API interface, supporting both local settings and centralized remote configuration. Each added operation corresponds to the creation of a new channel configuration item.

[0064] As an option, the system supports channel types including but not limited to:

[0065] Serial port protocols, such as RTU; Ethernet-based protocols, such as TCP and OPC-UA; message publish / subscribe protocols, such as MQTT; standard HTTP / REST interfaces; and custom script-driven protocols, supporting embedded scripting languages ​​such as JS and Lua.

[0066] After adding the channel, the user needs to configure its parameters. Specifically, the parameter fields should include at least the following:

[0067] Device address: A unique identifier for the device within the protocol it uses. For example, in the MODBUS protocol, this address is typically a slave number in decimal format, with a value generally ranging from 1 to 247.

[0068] Protocol type: This indicates the standard of the current channel communication protocol stack. The system will select the appropriate parser and frame constructor based on this information.

[0069] Communication ports: For serial ports, the port number is used (e.g., COM1 or / dev / ttyUSB0 for a MODBUS wireless 4G IoT gateway); for network ports, the port number is used (e.g., 192.168.1.100:502).

[0070] Sampling period: the minimum time interval for the device's data acquisition task, in seconds, with a configurable precision of 1 second;

[0071] Function code: A control field in the communication protocol used to identify the specific operation type. For example, in a MODBUS wireless 4G IoT gateway protocol, 0x03 indicates reading the holding register, and 0x06 indicates writing to a single register.

[0072] In some embodiments, the system supports advanced parameter configuration, such as the number of communication retries, timeout period, frame verification strategy, byte order type, etc. These parameters will be persistently stored inside the gateway device or a remote configuration server and will participate in the subsequent initialization process of the channel instance.

[0073] In one possible implementation, the system encapsulates the configuration results into a structured data channel function set definition structure, as follows:

[0074] ;

[0075] in: : Initialization function, used to open physical connections, complete handshake authentication, and allocate resources; : Periodic update function, triggered at a set periodic interval, to collect the latest data from the device; : Write function, used to send control commands or set parameters to the target device; The refresh function immediately retrieves the current device status and updates the cache. : Read function, returns the latest valid data from the local cache.

[0076] Each function in this function set is a single responsibility encapsulation. Typically, the system builds standard function templates for each type of channel; in programmable channel mode, users can customize the behavior logic of these functions.

[0077] To ensure the independence of the function set's runtime environment and the consistency of the system scheduling mechanism, each function must adhere to a unified interface signature specification and possess input validation and exception handling capabilities. Specifically, the initialization function... The return value must include information such as the communication connection status identifier, error code, and device response time. The system will use this information to determine the availability of the channel.

[0078] The following parameter definitions are involved in the function call process:

[0079] :in Indicates a unique identifier for the channel; Indicates the communication port configuration; Indicates the device address;

[0080] :in Indicates the task trigger timestamp;

[0081] :in Indicates the target register number or field name; Indicates the value to be written (which can be a number, boolean, or structure). No additional parameters are required; the current state must be read. Data is read directly from the cache without any external communication process;

[0082] The above function structure forms the core operational framework of the data channel, and all parameter definitions must be finalized during the configuration phase. The system will then build a scheduling dependency graph based on this and execute the initialization test process.

[0083] After all configurations are complete, the system moves to the next stage: the instantiation of the data channel. This process formally creates the channel object, registers it with the scheduling system, and initiates periodic tasks based on the set parameters.

[0084] S2. Instantiate the data channels, each data channel including an initialization function, a periodic update function, a write function, a refresh function, and a read function;

[0085] After completing the data channel configuration parameter settings (see step S1), the system needs to further map the configured logical description into operable instance objects. This process is not only the starting point for the transformation from static configuration to dynamic scheduling, but also the core step in realizing the "communication ready state" during the system initialization phase.

[0086] Normally, the instantiation of a data channel is completed by the system's main control module during the initialization process. The generated instance object must have a standard interface set and immediately execute the channel initialization logic to ensure the device is online and available. During this process, the channel will complete tasks such as method registration, resource binding, buffer initialization, and device handshake, providing comprehensive preparation for the scheduler's execution.

[0087] In this embodiment, the system initiates a channel instantiation task based on a configuration file or user settings. This task is identified as a MODBUS wireless 4G IoT gateway channel startup phase during the system initialization process, and is generally executed automatically after the device is powered on or the system is restarted.

[0088] The system first reads the parameter set for each channel: protocol type; communication interface; device address; sampling period; function code set; and other advanced configurations (such as byte order, timeout, retry strategy, etc.).

[0089] Next, based on the channel type and protocol attributes, the system loads the matching driver template and dynamically constructs the channel instance object. This object is an interface-oriented encapsulation unit, which internally contains pointers to the following five types of methods:

[0090] ;

[0091] in: Used to establish communication connections, request resource handles, and initialize buffers; : Executes the data acquisition logic of the periodic equipment; Write the set value to the target device; : Perform an immediate refresh operation; Used to read the latest data value from the local cache.

[0092] Alternatively, the object can be implemented as a C language struct or a C++ class, supporting method polymorphism and state persistence.

[0093] After function registration is complete, the system immediately executes the initialization method. Its function prototype is defined as follows:

[0094] ;

[0095] in: : Unique identifier for the channel; Physical communication port configuration, such as serial port number or IP address and port pair; Device address; : Initialize the context parameter set, including handshake method, communication mode, baud rate, parity bit, etc.; : Initialize the status flag, returning 1 for success and 0 for failure; Initialization operation time, in milliseconds; If it fails, return an error code or exception description.

[0096] The function execution process mainly includes: opening the communication port; creating a data cache structure; allocating communication buffer resources; performing handshake authentication (such as password authentication and encrypted channel initialization); and recording the channel status log.

[0097] S3. Start the timer to trigger the periodic update function according to the sampling period;

[0098] After the system completes the construction of the channel instance and method binding (see step S2), a timed scheduling mechanism needs to be started to enable periodic access and status updates of the data channel.

[0099] Typically, the system creates timer tasks, enabling the scheduler to proactively trigger data acquisition functions at preset sampling intervals. This mechanism avoids passive polling, improves resource utilization efficiency, and enhances system response stability.

[0100] As a key triggering component in the data scheduling chain, the timer's operating accuracy directly affects data sampling consistency and time alignment capabilities. Therefore, its implementation must ensure minimal jitter in scheduling granularity and robust response to abnormal conditions.

[0101] In this embodiment, the system provides each channel Create the corresponding periodic timer task The timer's operating parameters are determined by the "Sampling Interval" field in the channel configuration.

[0102] Specifically, the system executes the following logic after initialization:

[0103] Read the channel instance object bound to Method: Extract the channel's configuration parameter set; create a periodic trigger structure and bind the callback function to the channel's update method.

[0104] Timer task It can be formally expressed as the following tuple:

[0105] ;

[0106] in: : The channel number to which the timer belongs; : Sampling period, in seconds, represents the minimum time interval between two triggers; Initial delay time: Used to set the first trigger time after the timer starts; : The pointer to the update function that is periodically triggered.

[0107] As an option, the system supports period configuration with an accuracy of 1 second, and also allows configuration of start offset time to activate multiple channel tasks in a staggered manner to avoid scheduling congestion.

[0108] In some embodiments, timer tasks are managed uniformly by the system task scheduling engine and scheduled at runtime using a thread pool or event loop to reduce thread switching overhead. The task triggering model can be represented by the following abstract logic:

[0109] ;

[0110] in: : indicates the first The system timestamp that triggered this task; Channel number, used for indexing scheduling context and data caching.

[0111] function After being invoked by the scheduler, a device communication process will be automatically initiated to update the cache content, mark the time stamp, and write the result to the data channel status table.

[0112] To ensure the accuracy and controllability of triggering, the system's internal timer scheduling module must support the following additional mechanisms: support for task pause, resume, and cancellation operations; support for recording task execution statistics, including the number of triggers and the number of abnormal interruptions; and support for asynchronous listening to callback execution status and error capture.

[0113] In some implementations, the system provides status monitoring fields for timer tasks, for example:

[0114] Current status (running, suspended, canceled); last trigger time; next expected trigger time; last execution result (successful for one type of MODBUS wireless 4G IoT gateway / failed for one type of MODBUS wireless 4G IoT gateway / reason for one type of MODBUS wireless 4G IoT gateway exception), etc.

[0115] This information can be exposed externally via API or graphical interface to assist administrators in operation and maintenance monitoring and system optimization.

[0116] In one specific implementation, the timer module can be implemented using the following structure definition:

[0117] ;

[0118] The meanings of the fields are as follows: Periodic interval (corresponding) ); Startup delay (corresponding) ); : Function pointer, pointing to ; : Whether to enable the status boolean value; The system timestamp of the last execution; : Expected next execution time.

[0119] This structure will be managed uniformly by the scheduler and configuration items can be dynamically updated to ensure the correctness and maintainability of tasks during long-term system operation.

[0120] After all timer tasks are created and successfully started, the system enters normal operation, and the data channel will complete the data update task according to the periodic scheduling rhythm.

[0121] This stage marks the transition of the system from "initialization" to "stable operation," providing reliable underlying data support for upper-level business modules (such as data reporting, event triggering, and anomaly detection).

[0122] S4. Receive external requests, including read requests, write requests, or refresh requests, and add the requests to the request scheduler;

[0123] After the internal scheduling mechanism of the system is running normally and ensures the periodic execution of data acquisition (see step S3), in order to meet the access and control requirements of external systems for the data channel, a unified API request mechanism needs to be built so that external platforms can access the channel status, operate the equipment, and force refresh the data in real time through standard interfaces.

[0124] Typically, external systems send data requests to the gateway via network interfaces (such as HTTP, RESTful, MQTT, WebSocket, etc.). The system needs to identify the target of the call, execute the corresponding action, and return the result to the caller. This process requires the interface design to have a clear instruction format, precise access control, and full support for asynchronous communication and status feedback.

[0125] In this embodiment, the system is designed with a set of standard API interfaces bound to the data channel, which mainly include the following three types of calling behaviors:

[0126] : Read the current cached value of the specified channel;

[0127] Write the target value to the device connected to the specified channel;

[0128] : Forcefully trigger the update function of this channel, immediately collect data from the device and refresh the cache.

[0129] The execution path of the above request needs to undergo authentication verification (such as Token, API key, MODBUS wireless 4G IoT gateway key, etc.) and channel permission verification, and be mapped to the corresponding internal method pointer set. middle.

[0130] In one specific implementation, the system internally maintains the following channel call mapping table:

[0131] ;

[0132] in: : Channel identifier provided by the external request; : The corresponding set of channel methods, see the interface structure defined in step S2 for details.

[0133] When an external request arrives, the system locates the corresponding interface function based on the channel number and executes the corresponding operation.

[0134] For example, the process of reading cached values ​​can be represented as:

[0135] ;

[0136] in: : Read function pointer; : The returned cached data value.

[0137] This call does not involve device communication, has a short response time, and is suitable for high-frequency access scenarios.

[0138] For a request to write to the device, the system will call the following interface function:

[0139] ;

[0140] in: Write the target value, which is usually an integer, floating-point number, or a sequence of bytes; Write function; : Operation result status (1 indicates success, 0 indicates failure). Error codes or exception information when failure occurs.

[0141] In some embodiments, the system supports a write value verification mechanism, that is, before calling the device, the input value is first judged for its range validity and type to prevent illegal operations from causing device abnormalities.

[0142] In another possible implementation, the forced update request would call the following function:

[0143] ;

[0144] in: : The time when this request was triggered; Periodic update function; The updated value; : The time elapsed from sending a request to receiving a response, in milliseconds; Status indicator (success or failure).

[0145] Under this call path, the system skips timer scheduling, directly initiates a complete data acquisition process, and updates the cache. This mechanism is commonly used for data diagnostics, remote debugging, or intervention by higher-level strategies.

[0146] To facilitate interface integration and expansion, the system also defines a unified request / response structure template.

[0147] To improve API call efficiency, the system supports asynchronous request execution and a callback mechanism. That is, the task ID is returned immediately after the request is sent, and the caller can access it through: This design allows you to query task execution results and is suitable for remote device control operations with high latency.

[0148] At the same time, the system maintains the task context structure:

[0149] ;

[0150] The fields are described below: Task type (read a MODBUS wireless 4G IoT gateway / write a MODBUS wireless 4G IoT gateway / refresh a MODBUS wireless 4G IoT gateway). : Target channel number; issued_at: Task creation time; Task status (pending, running, finished, error). : Execution result data; : Explanation of the exception (if any).

[0151] This structure enables the system to support API call state persistence, result auditing, and call chain backtracking analysis.

[0152] To enhance the real-time interaction between external systems and data channels, the system also supports a MODBUS wireless 4G IoT gateway Webhook callback mechanism. When a data update, successful write, or abnormal alarm occurs on a designated channel, the system will push the event information to the URL registered by the external system, forming a complete event notification loop.

[0153] S5. Request the scheduler to schedule the execution of the function according to the preset priority rules, with the priority from high to low as refresh function, write function, and periodic update function;

[0154] Based on the stable operation of periodic timer-triggered tasks (see step S3) and external API request access (see step S4), the system needs to build a unified task scheduling center to centrally manage and schedule the execution of all types of channel requests.

[0155] Generally, regardless of whether a task originates from a timer, an external call, or an internal system trigger, it must enter a unified scheduling request queue. This design effectively resolves the execution order conflict caused by asynchronous task triggering and ensures that critical tasks (such as forced refreshes) are completed first through a configurable scheduling strategy.

[0156] The scheduler operates on an event-driven model, dynamically detecting tasks in the request queue, sorting them according to a predefined priority function, and executing them one by one in priority order. The system ensures that high-priority tasks are not blocked by low-priority queues by setting schedulable windows, maximum concurrency, and a blocking fallback mechanism.

[0157] In this embodiment, the scheduling queue structure is defined as follows:

[0158] ;

[0159] Each task item It is a structure like this:

[0160] ;

[0161] The parameters are explained below: Channel number, indicating the target of this task; : Task type, with possible values ​​including flush (force flush), write (write to device), update (timed update); : Task received timestamp, in milliseconds; : Task priority value, used for scheduling and sorting.

[0162] As an alternative, the system defines the following priority enumeration table:

[0163] : flush is a MODBUS wireless 4G IoT gateway operation (force refresh); 2: Write a MODBUS wireless 4G IoT gateway operation (write to device); 1: Update a MODBUS wireless 4G IoT gateway operation (periodic update); in each scheduling round, the scheduler first presses... Sort by value in descending order, then sort tasks with the same priority by Arranged in ascending order to ensure first-come, first-served service.

[0164] In one possible implementation, the scheduler's task ordering function is formally expressed as:

[0165] ;

[0166] This sorting function is stable, avoids uncontrollable scheduling order, and ensures that real-time tasks are scheduled first.

[0167] In some embodiments, to further improve system throughput, the scheduler employs a multi-channel parallel processing model, where each channel has an independent execution thread or coroutine context in a multi-core environment. The scheduler is only responsible for task dispatching; the execution logic is handled by the function pointers bound to the tasks.

[0168] For example, for periodic update tasks:

[0169]

[0170] After scheduling, it will be mapped to:

[0171] ;

[0172] After the callback function returns, the system records the running status, error code, and time consumed.

[0173] To prevent request queue overload, the system defines the following runtime status parameters: queue_size_max: maximum allowed queue length; active_tasks: number of tasks currently executing; task_timeout_ms: maximum allowed execution time for a single task; queue_backpressure: flag indicating whether the queue is currently in a blocked or discarded state.

[0174] When the queue length exceeds the set threshold, the system will activate a blocking protection mechanism and handle new requests according to the following strategy: high-priority tasks can still be enqueued; low-priority tasks are temporarily rejected and an error code is returned. Administrators can set retry policies or queue cleanup thresholds.

[0175] To support the recording of task behavior and the evaluation of scheduling efficiency, the system maintains the following scheduling log structure:

[0176] ;

[0177] Where: task_id: unique task ID; type: task category; enqueue_time: time when the task entered the queue; start_time: time when the task started execution; end_time: time when the execution was completed; status: execution result (success / fail / timeout); error_msg: error message (if any).

[0178] This information can be used for task scheduling monitoring, system bottleneck analysis, or execution trajectory backtracking.

[0179] S6. Classify and process the scheduling tasks, and perform the corresponding device access operations or data processing operations according to the function type.

[0180] After the scheduler completes the sorting and scheduling of tasks in the request queue (see step S5), the system needs to clearly distinguish the execution logic according to the task type to form a unified task processing framework.

[0181] Generally, task types can be divided into four categories: update (periodic update), read (read cache), write (write control), and flush (forced flush). The system identifies a MODBUS wireless 4G IoT gateway type_k through the task type, selects the corresponding processing module, and calls the method function bound to the channel.

[0182] As an option, the system internally uses a pre-defined mapping table between task types and function execution modules:

[0183] ;

[0184] in: : The module that handles update tasks; : Read cached task module; : Control write task module; Force refresh module.

[0185] Each module includes task execution logic, return structure, caching operation strategy, and exception handling mechanism. The contents of each module are described in detail below.

[0186] S6-1: Handling a MODBUS wireless 4G IoT gateway update request.

[0187] In this embodiment, for a task that updates a MODBUS wireless 4G IoT gateway type, the system calls the update function defined in the channel definition:

[0188] ;

[0189] in: : Acquired device data; Status code (1 indicates success for the MODBUS wireless 4G IoT gateway, 0 indicates failure for the MODBUS wireless 4G IoT gateway).

[0190] After successful acquisition, the system will Write channel cache structure:

[0191] ;

[0192] S6-2: Handling a MODBUS wireless 4G IoT gateway read request.

[0193] In one possible implementation, for a MODBUS wireless 4G IoT gateway read task, no device communication is performed; instead, the previous record is read directly from the cache structure.

[0194] ;

[0195] The system constructs a response structure and returns it immediately. This type of task has extremely low response latency and is suitable for scenarios such as high-frequency access and front-end polling.

[0196] S6-3: Processing a MODBUS wireless 4G IoT gateway request; writing a MODBUS wireless 4G IoT gateway request.

[0197] Specifically, for a MODBUS wireless 4G IoT gateway write task, the scheduler calls the write function:

[0198] ;

[0199] in: : The control value requested by the user; : Channel-bound write function; Error description or device return code when failure occurs.

[0200] After a successful write operation, the system can selectively store the written value in the "write operation cache" and update the actual cache during the next refresh or synchronization process to reduce the problem of repeated states after writing.

[0201] S6-4: Handling a MODBUS wireless 4G IoT gateway flush request

[0202] In one implementation, flushing a MODBUS wireless 4G IoT gateway task triggers a complete data fetch process to meet higher real-time requirements.

[0203] The execution function takes the following form:

[0204] ;

[0205] The system updates the result to the main cache:

[0206] ;

[0207] This task usually has the highest priority (see step S5) and is suitable for scenarios such as alarm response, policy interruption, and manual intervention.

[0208] To avoid excessive load caused by frequent device access, the system is designed with a "minimum refresh interval" strategy to ensure that the time interval between two MODBUS wireless 4G IoT gateway flush operations is not less than a threshold. To avoid jitter control.

[0209] After the task is completed, the system will perform post-processing procedures according to the task type, including cache marking, task log recording, and exception flag updating.

[0210] At this point, through the scheduler's task distribution logic, the system has completed the unified execution and cache update process for channel operation tasks, laying the foundation for subsequent state management and consistency maintenance.

[0211] Before the task distribution and execution process (see step S6) begins, the system scheduler needs to execute a complete scheduling safety verification mechanism to pre-detect potential functional dependency cycles, method chain deadlocks, or control flow anomalies. Generally, this mechanism is built upon the "call graph" model of the task scheduling engine.

[0212] The system introduces a dependency graph construction and loop detection mechanism before task execution. The scheduler constructs a directed graph structure based on the functions, script modules, channel interface methods, etc. referenced by the task to be executed. The edges in the graph represent "call relationships", and the nodes represent "function units" or "channel operation encapsulations".

[0213] In this embodiment, the function call graph The definition is as follows:

[0214] ;

[0215] in:

[0216] : Represents a function or module unit; : Indicates a directed edge, if it exists ,express Directly called .

[0217] To detect potential function recursion in scheduling, the system needs to determine the graph. Does a directed cycle exist in it?

[0218] In one possible implementation, the system uses topological sorting or depth-first search (DFS) to detect loops. If the following structure is detected:

[0219] ;

[0220] This indicates the existence of a circular dependency path. The system will immediately interrupt the scheduling process of the task and generate an exception log.

[0221] As an extension mechanism, the system dynamically maintains a call path table for each task. The definition is as follows:

[0222] ;

[0223] Each of them Indicates the current task The first function in the function graph called Each node. The system records path growth in real time during the call process and performs loop detection operations on newly added nodes.

[0224] To improve analysis efficiency, the system employs a cached call graph static pre-compilation mechanism. Specifically, during system loading or task definition import phases, all module dependency graphs are pre-generated; during each task scheduling, only local verification is performed on the existing graph structure; if a newly added module reference is not compiled and recorded, the system enters the incremental graph construction process.

[0225] This method can significantly reduce the overhead of online graph detection and is suitable for environments with large workloads and complex module references.

[0226] Specifically, the system binds function dependency detection with scheduling control, and will refuse to execute a scheduled task when one of the following conditions is met:

[0227] There is a loop in the task call graph;

[0228] The call path length exceeds the limit threshold. ,Right now:

[0229] ;

[0230] Node depth recursion exceeds limit, meaning the same node in... More than Second-rate;

[0231] An interface combination that is not allowed to be called appears, such as a MODBUS wireless 4G IoT gateway flush method nesting a MODBUS wireless 4G IoT gateway write method, which violates the task design principle.

[0232] As an option, the system provides a security incident response mechanism. When an illegal call graph or unacceptable dependency structure is detected, the system automatically logs the exception event:

[0233] ;

[0234] The fields are defined as follows: task_id: trigger task number; detect_time: anomaly detection time; type: anomaly type (cycle / depth, violation / invalid, ref); graph_hash: hash digest of the current task dependency graph; path: problem call path; reason: explanation of the scheduling rejection reason.

[0235] This log is used by system administrators for post-event analysis, script developers for backtracking issues, and can be exported as a scheduling exception report.

[0236] In one specific implementation, the system sets configurable threshold parameters, including: L_max: maximum allowed call path length; D_max: maximum number of repetitions of the same node; T_detect: maximum execution time of graph detection (used to protect the analysis process from abuse); GraphPolicyMap: specifies the function combination strategy allowed for the task type.

[0237] Only after all scheduling security checks are completed can the system enter the actual task execution phase, and the scheduler will call the corresponding processing module (see step S6). If the check fails, the task will be terminated in the security verification phase, and the system will not perform any actual operations on any device or channel, thereby ensuring the stability and consistency of the core control chain.

[0238] The embodiments described in this specific implementation are preferred embodiments of this application and are not intended to limit the scope of protection of this application. Identical components are represented by the same reference numerals. Therefore, all equivalent changes made to the structure, shape, and principle of this application should be covered within the scope of protection of this application.

Claims

1. A MODBUS wireless 4G IoT gateway, comprising a bottom cover (1), characterized in that, The bottom cover (1) has a circuit board (3) installed inside. The top cover (2) is inserted into the top of the bottom cover (1). After the top cover (2) and the bottom cover (1) are engaged, they form a complete gateway shell. The bottom cover (1) has a cooling fan (6) installed inside to drive airflow. The circuit board (3) has a partition (5) installed on top. The cooling fan (6) is placed between the partition (5) and the inner wall of the bottom cover (1). The bottom cover (1) also has an air duct (4) installed inside to divide the airflow. Both the bottom cover (1) and the top cover (2) have heat-conducting components installed inside, and the heat-conducting components abut against each other.

2. The MODBUS wireless 4G IoT gateway according to claim 1, characterized in that, The air duct (4) includes a housing (41), which is fixedly installed on the inner wall of the bottom cover (1). A baffle (42) is installed on the front side of the housing (41), and an air inlet (43) and an air outlet (44) are separated at both ends of the housing (41) by the baffle (42).

3. The MODBUS wireless 4G IoT gateway according to claim 1, characterized in that, The heat-conducting assembly includes a heat-conducting plate one (7) and a heat-conducting plate two (9). The heat-conducting plate one (7) is fixed and penetrates the side wall of the bottom cover (1). The heat-conducting plate two (9) is fixed and penetrates the side wall of the top cover (2). The heat-conducting plate one (7) is equipped with a heat dissipation fin one (8) on the side inside the bottom cover (1). The heat-conducting plate two (9) is equipped with a heat dissipation fin two (10) on the side outside the top cover (2).

4. The MODBUS wireless 4G IoT gateway according to claim 3, characterized in that, The heat-conducting plate one (7) and the heat-conducting plate two (9) abut against each other, and thermal grease is coated between the heat-conducting plate one (7) and the heat-conducting plate two (9).

5. A method for operating a gateway data channel, characterized in that, The MODBUS wireless 4G IoT gateway according to any one of claims 1-4 includes the following steps: S1. Configure parameters for multiple data channels, including at least protocol type, device address, function code, communication port, and sampling period; S2. Instantiate the data channels, each data channel including an initialization function, a periodic update function, a write function, a refresh function, and a read function; S3. Start the timer to trigger the periodic update function according to the sampling period; S4. Receive external requests, including read requests, write requests, or refresh requests, and add the requests to the request scheduler; S5. Request the scheduler to schedule the execution of the function according to the preset priority rules, with the priority from high to low as refresh function, write function, and periodic update function; S6. Classify and process the scheduling tasks, and perform the corresponding device access operations or data processing operations according to the function type.

6. A gateway data channel operation method according to claim 5, characterized in that, Each of the data channels consists of a set of standard functions, which includes: The initialization function is used to establish a communication connection with the device and initialize resources; The periodic update function is used to collect device data according to a set period. The write function is used to write control commands or set values ​​to the device; The refresh function is used to request the status from the device and update the local cache immediately; The read function is used to return the most recent valid data from the local cache.

7. A gateway data channel operation method according to claim 5, characterized in that, The request scheduler employs a priority-based sorting scheduling mechanism: First, the priority is determined based on the request type. Refresh requests have a higher priority than write requests, and write requests have a higher priority than periodic update requests. In the case of requests of the same type, they are sorted according to the order in which they arrived. The sorted requests are scheduled and executed sequentially.

8. A gateway data channel operation method according to claim 5, characterized in that, Before scheduling a task, the system constructs a call dependency graph between task functions. The nodes in this graph represent function entities, and the edges represent direct call relationships between functions. By performing a topological sort on this dependency graph, if a loop is detected, it is determined that there is a risk of recursion or deadlock. The system then suspends the execution of the task and issues an exception message.

9. A gateway data channel operation method according to claim 5, characterized in that, The timer triggers the periodic update function with a minimum granularity of one second, and satisfies the following conditions: The scheduling system is modeled as a queuing system with a single service channel; Within any given time period, the average arrival rate of tasks is lower than the scheduler's processing rate. The average waiting time for each periodic update task is less than its corresponding set update cycle, so as to ensure that the periodic task can be completed within a limited time.

10. A gateway data channel operation method according to claim 5, characterized in that, The data channel includes a preset type channel and a programmable type channel: The preset type channel is generated according to the system configuration file and the communication logic is constructed using a standard protocol structure; The programmable type channel is defined by the user through scripts, specifying the execution logic of various functions. When a programmable channel is set to exclusive execution mode, the system allocates a separate scheduler thread resource to it to isolate its running environment.

Images