Modbus master station control system for multi-queue task scheduling

Abstract

The invention discloses a Modbus master station control system for multi-queue task scheduling, and relates to the technical field of automatic control. A multi-queue task scheduling architecture is adopted, firstly, hierarchical classification is performed on Modbus communication tasks according to functional characteristics of the Modbus communication tasks, then different types of tasks are placed in independent task queues with different scheduling strategies, and finally, the tasks are scheduled by a task scheduling manager according to priorities and scheduling strategies of the queues. And in combination with an intelligent optimization mechanism based on historical communication performance data analysis, tasks are efficiently and orderly scheduled and executed, so that the communication efficiency of the Modbus network, the emergency task response speed and the overall reliability of the system are remarkably improved.

Description

Technical Field

[0001] This invention relates to the field of automation control technology, and in particular to a Modbus master station control system for multi-queue task scheduling. Background Technology

[0002] In the field of modern industrial automation, the Modbus master station control system serves as the core architecture for multi-device management, and its task scheduling mechanism directly affects system performance.

[0003] Current mainstream technical solutions primarily employ two scheduling methods: single-queue polling and simple priority scheduling. However, both reveal significant shortcomings in complex and dynamic industrial scenarios. The single-queue polling mechanism mixes tasks of different natures (such as low-frequency configuration tasks and high-frequency data acquisition tasks), causing long-running tasks to block subsequent critical operations. Furthermore, single-point device failures or network anomalies can trigger full queue blocking. Additionally, the lack of task type adaptation leads to inefficient use of communication bandwidth and processing resources. While the simple priority mechanism partially alleviates the single-queue problem through hierarchical scheduling, it suffers from issues such as coarse priority division (failing to distinguish the urgency differences of similar high-priority tasks), high-priority saturation leading to low-priority task starvation, and static priorities failing to adapt to dynamic changes in device status and network quality.

[0004] The inherent shortcomings of the aforementioned scheduling mechanisms are becoming increasingly apparent when faced with the ever-increasing number of devices and increasingly complex application scenarios. These shortcomings not only severely limit the improvement of system performance but also cause a series of serious problems in practical applications, such as data latency, decision-making delays, and potential production safety hazards. Therefore, developing a new type of task scheduling system that is more efficient, reliable, and adaptable has become an urgent need to address current technical pain points. Summary of the Invention

[0005] The purpose of this invention is to provide a Modbus master station control system for multi-queue task scheduling, which fundamentally solves the problem of conflicting access rights for different types of tasks to a single communication channel, and achieves a significant improvement in system communication efficiency and response performance.

[0006] To achieve the above objectives, the present invention provides the following technical solution.

[0007] This invention provides a Modbus master station control system for multi-queue task scheduling, comprising: The multi-level task queue module is configured to classify and store received Modbus communication tasks into at least two independent task queues with different scheduling priorities according to preset task function characteristics. The task scheduling manager, which is connected to the multi-level task queue module, is configured to select communication tasks to be executed from the queue with the highest priority according to the preset scheduling priority of the independent task queues during the scheduling period. The Modbus communication protocol stack, which is connected to the task scheduler, is configured to convert the communication task to be executed into Modbus messages and communicate with the slave device.

[0008] Optionally, the multi-level task queue module includes: A real-time task queue is used to store highly urgent tasks; Configure the task queue to store device configuration tasks; The data task queue is used to store periodic data acquisition tasks; The scheduling priority of the real-time task queue is higher than that of the configuration task queue and the data task queue.

[0009] Optionally, the task scheduler is configured to employ scheduling strategies for different queues, including: A preemptive scheduling strategy is adopted for the real-time task queue; The configuration task queue adopts a first-in-first-out scheduling strategy; A round-robin scheduling strategy is adopted for the data task queue.

[0010] Optionally, the system also includes a slave device management module, configured to maintain a set of historical communication performance data for each slave device.

[0011] Optionally, the task scheduler is further configured to dynamically adjust the timeout or retry strategy when communicating with the corresponding slave station based on the historical communication performance data.

[0012] Optionally, the system further includes an adaptive communication optimization module, configured to dynamically adjust the polling order of tasks in the data task queue based on the historical communication performance data.

[0013] Optionally, the adaptive communication optimization module is further configured to automatically reduce the polling frequency of a slave device when the historical communication performance data of a slave device shows that its communication has failed continuously.

[0014] The beneficial effects of this invention are: (1) Significantly improve system response performance: By establishing a real-time task queue with a preemptive scheduling strategy, it is ensured that emergency tasks can bypass the queuing and waiting of the regular task queue, and their response time is not affected by other tasks, thereby improving the system's response speed in emergency situations by at least 60%, which is of great significance for ensuring industrial production safety. (2) Significantly improve communication efficiency: By classifying and processing different types of tasks and using the adaptive communication optimization module to dynamically adjust the polling order and tilt communication resources toward high-quality nodes, the time wasted due to waiting for slow devices or retrying faulty devices is effectively reduced, thereby increasing the effective utilization rate of bus bandwidth by at least 40%. (3) Enhance system reliability and robustness: Through the collaborative work of the intelligent slave station management module and the adaptive communication optimization module, faulty or unstable slave station devices can be quickly identified and "soft isolated", avoiding the impact of a single node failure on the stable operation of the entire communication network, so that the availability of the system in complex electromagnetic environment or equipment aging conditions reaches more than 99.5%. (4) Reduce the development and maintenance costs of upper-layer applications and systems: The standardized multi-queue task management interface and automated communication optimization mechanism simplify the development logic of upper-layer applications (such as SCADA and HMI). Developers no longer need to pay attention to complex underlying communication scheduling and exception handling. At the same time, the full life cycle task status tracking also provides clear data support for system fault diagnosis and reduces the workload of system maintenance. Attached Figure Description

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

[0016] Figure 1 This is a functional module architecture diagram of a Modbus master station control system for multi-queue task scheduling provided in an embodiment of the present invention.

[0017] Figure 2 This is a flowchart of a core task scheduling method according to an embodiment of the present invention.

[0018] Figure 3 This is a lifecycle state transition diagram of a single task according to an embodiment of the present invention. Figure 4 This is a system deployment architecture diagram according to an embodiment of the present invention.

[0019] Figure 5 This is a task scheduling timing diagram according to an embodiment of the present invention.

[0020] Figure 6 This is a state transition diagram of a slave device according to an embodiment of the present invention. Detailed Implementation

[0021] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0022] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0023] Figure 1 This is a functional module architecture diagram of the Modbus master station control system for multi-queue task scheduling of the present invention. The architecture includes a master station controller, a task scheduling manager, a multi-level task queue module, a slave device management module, an adaptive communication optimization module, and a Modbus communication protocol stack.

[0024] The master controller, as the top layer of the system, is responsible for receiving control commands from upper-layer applications (such as SCADA and HMI).

[0025] The task scheduler is the core scheduling hub of the system. It receives instructions from the master controller, parses and converts them into specific Modbus communication tasks, and then distributes them to the corresponding task queues according to the nature of the tasks. In addition, it also determines which task in which queue should be executed at the current moment based on the scheduling strategy of each queue.

[0026] The multi-level task queue module is the core of this invention. Its purpose is to directly solve the problems of low scheduling efficiency and critical task response delay caused by the mixture of task types in the prior art, namely the aforementioned "hierarchical scheduling problem of multi-type tasks". By classifying and managing tasks, it provides differentiated processing channels for tasks with different characteristics.

[0027] This module contains three logically independent First-In-First-Out (FIFO) queues: a configuration task queue, a data task queue, and a real-time task queue. These three queues employ different scheduling strategies enforced by the task scheduler: the configuration task queue uses a standard FIFO scheduling strategy to ensure that tasks requiring sequential execution, such as parameter settings, are executed in a predetermined order; the data task queue uses a round-robin scheduling strategy, where the task scheduler periodically retrieves tasks from this queue to ensure fair and periodic data collection from each slave station, and its polling order and frequency are dynamically influenced by the intelligent optimization module; the real-time task queue uses a preemptive scheduling strategy with the highest priority, where the task scheduler immediately pauses any currently executing non-real-time tasks (after a complete Modbus transaction) and prioritizes tasks in this queue.

[0028] The slave device management module is responsible for maintaining the status information of all slave devices. By establishing and dynamically maintaining a historical communication performance dataset for each slave, the task scheduler can perform refined and differentiated management based on this data. This effectively overcomes the defects of "poor system responsiveness" and "lack of dynamic adjustment" caused by the use of fixed communication parameters in the existing technology. This is the foundation for the intelligent and adaptive capabilities of this invention.

[0029] After each communication interaction with the slave station, the system feeds back the result of the interaction (such as response time, success or failure) to this module. This module then updates the historical communication performance data of the corresponding slave station in real time (e.g., updating average_response_time ms using a sliding window or exponentially weighted moving average algorithm). When the task scheduler needs to make a timeout judgment or retry decision, it queries this module. Based on the historical communication performance data, this module provides a dynamically calculated communication timeout that is most suitable for the current state of the slave station. For example, a rule for calculating the dynamic timeout can be configured as: Dynamic Timeout = (Average Response Time * 1.5) + 50 milliseconds. This rule ensures that the timeout can adapt to the normal fluctuations of the device (based on 1.5 times its average response time) while having a fixed margin (50 milliseconds) to cope with occasional network latency, making it more flexible and efficient than a fixed timeout.

[0030] The adaptive communication optimization module is the core of the adaptive communication scheduling algorithm described in this invention. It works closely with the slave device management module and achieves the goal of dynamically tilting communication resources toward high-quality communication nodes by implementing mechanisms such as dynamically adjusting the task polling order and isolating abnormal devices based on communication success or failure. This proactively optimizes communication behavior, further improves the overall communication efficiency of the system, and solves the problems of "low resource utilization" and "lack of dynamic adjustment" in the existing technology.

[0031] This module periodically analyzes the historical communication performance data of all slave stations and dynamically adjusts the internal polling order of the data task queue. For example, it prioritizes slave stations with fast response times and good communication quality, and prioritizes those with slow response times. Furthermore, when this module detects that the communication status of a slave station meets preset "abnormal" conditions, it triggers an "abnormal device isolation" mechanism. In a preferred embodiment, the "abnormal" condition can be configured as follows: after isolation is triggered by a consecutive failure count > 5 or (total number of requests > 100 and failure rate > 30%), the system will temporarily and significantly reduce the polling frequency of that station in the data task queue (e.g., from once per second to once per minute), thereby avoiding wasting valuable communication time on communication with a high probability of failure. When the device recovers normal communication after low-frequency polling, the isolation state can be automatically lifted.

[0032] The Modbus communication protocol stack is responsible for converting upper-layer tasks into standard Modbus messages and conducting actual communication interactions with slave devices through physical communication interfaces (such as RS-485). The modules work collaboratively: the master controller receives instructions, the task scheduler distributes and schedules tasks, multi-level task queues classify and store tasks, the slave device management module and adaptive communication optimization module provide decision support, and finally, the Modbus communication protocol stack completes communication with the slave devices.

[0033] Figure 2 This is a flowchart of the core task scheduling method of the present invention, which mainly includes the following steps: Step 1, Receive Task: The master station controller receives control commands from the upper-layer application.

[0034] Step 2, Task Classification and Queuing: The task scheduler analyzes the nature of the instruction; if it is an emergency alarm task, it enters the real-time task queue; if it is a parameter setting task, it enters the configuration task queue; if it is a regular data acquisition task, it enters the data task queue.

[0035] Step 3, Scheduling Decision: At the beginning of each scheduling cycle, the task scheduler checks each queue in the following priority order: First, it checks if the real-time task queue is empty; if not empty, a real-time task is immediately retrieved and prepared for execution (preemptive); if the real-time task queue is empty, it checks if the configuration task queue is empty. If not empty, a configuration task is retrieved in FIFO order and prepared for execution; if both are empty, a data task is retrieved from the data task queue in an optimized round-robin order and prepared for execution.

[0036] Step 4, Task Execution: The selected task is handed over to the Modbus communication protocol stack for execution, and communication is established with the target slave station.

[0037] Step 5, Status Update: After the task is executed, update the task status according to the execution result (success, failure, timeout) and update the historical communication performance data of the corresponding slave station in the slave station device management module.

[0038] Step 6: Repeat step 3 to start the next scheduling cycle.

[0039] Figure 3 This is a lifecycle state transition diagram for a single task in this invention. A task will go through the following states from creation to termination: Pending: The task has been created and is waiting to be added to the scheduling queue.

[0040] Executing: The task has been selected by the task scheduler and is being executed by the Modbus communication protocol stack.

[0041] Completed: The task was successfully executed and a correct response was received from the slave station. This is a final status.

[0042] Failed: The task encountered an error during execution (such as receiving an abnormal response), or failed after reaching the maximum number of retries. This is a final state.

[0043] The transitions between states are triggered by the system's scheduling and execution results. For example, when a "pending" task is selected by the scheduler, its state changes to "in execution"; if the execution is successful, the state changes to "completed"; if the execution fails but the maximum number of retries has not been reached, its state may be reset to "pending" and the retry count will be incremented, waiting for the next scheduling.

[0044] Figure 4The system deployment architecture diagram of this invention shows a master controller connected via a Modbus bus to 10 temperature sensors (addresses 1-10), one frequency converter (address 11), and one I / O module (address 12) associated with an emergency stop button. This architecture maps the logical relationships between different devices and the multi-level task queues of this invention. The 10 temperature sensors (addresses 1-10) are the source of periodic data acquisition tasks. Due to their high-frequency and repetitive nature, these tasks are automatically assigned to the data task queue by the task scheduler after creation, and processed by the scheduler using an optimized polling strategy. The frequency converter (address 11) is the source of low-frequency configuration tasks. Parameter setting or mode switching commands to it are assigned to the configuration task queue and executed using a FIFO strategy to ensure the order of commands, with its execution priority higher than that of data tasks.

[0045] One emergency stop I / O module (address 12) is the source of high-urgency events. When the physical button is pressed, an associated stop task is created and immediately placed into the real-time task queue, which has the highest preemption privileges, ensuring that the critical safety response to this instruction can bypass all other regular tasks.

[0046] This diagram clearly illustrates how the multi-queue architecture of this invention logically decouples a physically hybrid bus system into three independent virtual channels with different qualities of service (QoS).

[0047] Figure 5 This is a task scheduling sequence diagram of the present invention. The diagram uses time as the axis and intuitively shows the dynamic process of the multi-queue scheduling mechanism through a series of typical events, including regular polling, configuration task insertion, real-time task preemption, fault injection and isolation, polling after isolation, and isolation recovery.

[0048] Regular polling phase (T0-T1): In the initial stage of the system, only data tasks exist. The task scheduler executes the tasks in the data task queue in the optimized polling order (such as polling addresses 1, 2, 3...).

[0049] Configuration Task Insertion (T2): At time T2, a configuration task for the frequency converter (address 11) is created. Since the configuration task queue has a higher priority than the data task queue, at the next scheduling decision point, the scheduler will pause polling of data tasks and execute the configuration task instead.

[0050] Real-time task preemption (T3): At time T3, an emergency stop task is created and enters the real-time task queue. The scheduler detects that the highest priority queue is not empty and immediately exercises its preemption right. As soon as the currently executing low-level Modbus communication transaction for the temperature sensor at address 4 ends, the scheduler no longer polls the next data task (e.g., address 5) as originally planned, but immediately retrieves the emergency stop task (address 12) from the real-time task queue and executes it. This process clearly demonstrates how preemptive scheduling ensures that the response of critical tasks is not affected by the queuing of regular tasks.

[0051] Fault Injection and Isolation (T4-T5): At time T4, in order to simulate a device failure scenario, the system injects a fault into the sensor with address 5, causing its communication to start to time out continuously. When the task scheduler tries to communicate with address 5, it will experience a complete timeout wait, which is represented as a long operation in the timing diagram. After failing to retries after a preset number of times, at time T5, the adaptive communication optimization module updates the device status to "isolated".

[0052] from Figure 5 It can be clearly observed that after T5, the regular data polling sequence completely skips address 5 and directly polls from address 4 to address 6, thereby completely removing the invalid waiting time caused by faulty equipment from the scheduling loop and ensuring the communication efficiency of healthy nodes.

[0053] Figure 6 The slave device state transition diagram of the present invention illustrates the state transition logic of the slave device on the master controller side, that is, it shows how a slave device transitions between three states: "Online", "Unstable", and "Isolated" based on the result of its communication success or failure.

[0054] For example, this embodiment is set up on a typical automated production line, which manages the following slave devices through a Modbus master controller: 10 temperature sensors (slave addresses 1-10), which need to read temperature data once per second (high-frequency data task); 1 frequency converter (slave address 11), which needs to send operating frequency parameters every 5 minutes (low-frequency configuration task); and 1 I / O module associated with the emergency stop button (slave address 12), which is used to report emergency stop signals (real-time task). In the initial stage of system operation, the communication quality of all devices is good.

[0055] Solution application and collaborative work: Normal operation: After the system is powered on, the upper-layer application will generate 10 data acquisition tasks for addresses 1-10 and one parameter configuration task for address 11.

[0056] The task scheduler puts these 10 data acquisition tasks into the data task queue and the parameter configuration task into the configuration task queue.

[0057] During each scheduling cycle, since the real-time task queue is empty, the task scheduler prioritizes checking the configuration task queue, which is also empty until the first 5 minutes. Therefore, the scheduler retrieves tasks from the data task queue in a round-robin order for execution, completing the periodic data acquisition from the 10 temperature sensors. The task status tracking module records the execution status of each task.

[0058] When the 5th minute arrives, a new configuration task is placed in the configuration task queue. In the next scheduling cycle, the scheduler will execute the configuration task first, and then continue to execute the polling tasks in the data task queue after the configuration task is completed.

[0059] At a certain moment, the operator presses the emergency stop button, and the I / O module (address 12) notifies the master controller in some way (such as hardware interrupt or fast polling), and the master controller immediately generates an emergency stop task.

[0060] The task scheduler identifies the urgency of the task and adds it to the real-time task queue.

[0061] At the very beginning of the next scheduling cycle, the task scheduler detects a task in the real-time task queue and immediately executes a preemptive scheduling strategy. It waits for any Modbus communication transactions currently in progress to complete, and at the next scheduling decision point, it immediately suspends the scheduling of the configuration or data task queue and instead retrieves an emergency stop task from the real-time task queue and executes it.

[0062] This ensures that emergency shutdown commands are processed and executed with the highest priority and at the fastest speed, unaffected by any other routine tasks.

[0063] Adaptive adjustment to degradation in slave communication quality: Suppose that after running for a period of time, due to circuit aging, the temperature sensor at address 5 begins to experience response delays and communication packet loss.

[0064] After each communication with the sensor at address 5, the task status tracking module records the high response time and communication failure results.

[0065] Based on these records, the slave device management module continuously updates the historical communication performance data of the sensor at address 5. The "average response time" in the data will increase significantly, and the "error rate" will continue to rise.

[0066] The adaptive communication optimization module periodically detects deterioration in the historical communication performance data of address 5. In response, it prioritizes address 5 in the data task queue, moving it further down the polling order.

[0067] If the situation worsens further and the number of consecutive failures exceeds the threshold, the adaptive communication optimization module will trigger an isolation mechanism, which will greatly reduce the polling frequency of address 5 (for example, from once per second to once every 30 seconds).

[0068] In this way, the system avoids wasting a lot of time on invalid communication with this "bad" device, ensuring the data acquisition efficiency of the other nine normal temperature sensors and the stability of the entire system.

[0069] To highlight the technical effects of the present invention, the embodiments of the present invention are analyzed below in comparison with existing technologies (such as single-queue polling): During normal operation, the inverter configuration task, which occurs every 5 minutes and can take a long time, will directly block the data acquisition of all subsequent temperature sensors, resulting in data interruptions lasting for several seconds or even longer.

[0070] When an emergency stop signal is generated, if there is a slow task in progress (such as trying to communicate with an unresponsive device), the emergency instruction must be queued and wait until the preceding task times out. This wastes valuable emergency response time and may lead to a safety incident.

[0071] When the communication quality of the sensor at address 5 deteriorates, the system spends a significant amount of time waiting for that sensor to time out in each polling cycle. This greatly prolongs the complete polling cycle for all 10 sensors, severely impacting the real-time performance of all data.

[0072] This comparison clearly demonstrates the significant advantages of the present invention in terms of task scheduling efficiency, emergency task response speed, and system robustness.

[0073] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0074] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. Furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A Modbus master station control system for multi-queue task scheduling, characterized in that, include: The multi-level task queue module is configured to classify and store received Modbus communication tasks into at least two independent task queues with different scheduling priorities according to preset task function characteristics. The task scheduling manager, which is connected to the multi-level task queue module, is configured to select communication tasks to be executed from the queue with the highest priority according to the preset scheduling priority of the independent task queues during the scheduling period. The Modbus communication protocol stack, which is connected to the task scheduler, is configured to convert the communication task to be executed into Modbus messages and communicate with the slave device.

2. The Modbus master station control system for multi-queue task scheduling according to claim 1, characterized in that, The multi-level task queue module includes: A real-time task queue is used to store highly urgent tasks; Configure the task queue to store device configuration tasks; The data task queue is used to store periodic data acquisition tasks; The scheduling priority of the real-time task queue is higher than that of the configuration task queue and the data task queue.

3. The Modbus master station control system for multi-queue task scheduling according to claim 2, characterized in that, The task scheduler is configured to employ scheduling strategies for different queues, including: A preemptive scheduling strategy is adopted for the real-time task queue; The configuration task queue adopts a first-in-first-out scheduling strategy; A round-robin scheduling strategy is adopted for the data task queue.

4. The Modbus master station control system for multi-queue task scheduling according to claim 1, characterized in that, The system also includes a slave device management module, which is configured to maintain a set of historical communication performance data for each slave device.

5. A Modbus master station control system for multi-queue task scheduling according to claim 4, characterized in that, The task scheduler is also configured to dynamically adjust the timeout or retry strategy when communicating with the corresponding slave station based on the historical communication performance data.

6. A Modbus master station control system for multi-queue task scheduling according to claim 4, characterized in that, The system also includes an adaptive communication optimization module, configured to dynamically adjust the polling order of tasks in the data task queue based on the historical communication performance data.

7. A Modbus master station control system for multi-queue task scheduling according to claim 6, characterized in that, The adaptive communication optimization module is also configured to automatically reduce the polling frequency of a slave device when the historical communication performance data of a slave device shows that its communication has failed continuously.

Images