Industrial control data processing system and method based on embedded real-time operating system

Abstract

The invention discloses an industrial control data processing system and method based on an embedded real-time operating system, and relates to the technical field of industrial automation control, and the industrial control data processing system comprises a dynamic weight evaluation module, a resource elastic distribution module and a dual self-healing verification module; and the dynamic weight evaluation module is used for generating a dynamic weight value according to the task type, the data security level, the deadline margin and the historical execution abnormal rate. According to the industrial control data processing system and method based on the embedded real-time operating system, the task criticality is quantified in real time through the dynamic weight evaluation module, and the real-time response capability and the resource utilization efficiency of the industrial control system are improved in combination with elastic resource allocation driven by load prediction. A dynamic weight mechanism ensures that the emergency task can instantly preempt resources, and the problem of low-priority task blocking caused by traditional static priority scheduling is avoided.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of industrial automation control, in particular to an industrial control data processing system and method based on an embedded real-time operating system. BACKGROUND

[0002] In the field of industrial control, the embedded real-time operating system undertakes the core responsibility of high-precision data processing and real-time task scheduling, and its performance directly affects the stability and response efficiency of the production line. With the complication of intelligent manufacturing scenarios, the data scale and task types handled by industrial equipment grow exponentially, such as high-speed sensor signal acquisition, multi-axis motion control instruction generation, abnormal state monitoring, etc. These tasks are often executed concurrently and the load fluctuates dynamically. However, in the existing control system based on the embedded real-time operating system, the task scheduling and resource allocation mechanism cannot adapt to the dynamic load environment, which becomes a bottleneck problem restricting the real-time performance and resource utilization of the system. Traditional technologies use fixed priority task scheduling strategies, which assume that the system load is relatively static and the task period and resource demand can be determined in advance. However, in actual industrial scenarios, dynamic factors such as production line speed adjustment, sudden fault response, and instantaneous influx of multi-source heterogeneous data frequently occur, resulting in significant uncertainty in system load. At this time, long-term occupation of computing resources by high-priority tasks can cause blocking of low-priority tasks, and critical non-periodic tasks such as emergency shutdown instructions may be delayed due to the inability to obtain resources in time, which can cause production accidents. On the other hand, the system resource allocation strategy is out of touch with the real-time load state, and the task queuing delay is aggravated during high-load periods, while the resource idle rate rises during low-load periods, making it difficult to achieve flexible scaling of computing resources. In addition, when the dependency relationship between tasks changes dynamically, the fixed scheduling logic can easily induce resource competition deadlock, which requires manual intervention to recover, seriously weakening the system reliability. Existing improvement schemes mostly focus on optimizing scheduling algorithms or increasing hardware redundancy, but fail to solve the contradictions between dynamic load perception, resource elastic allocation, and task real-time scheduling from the system level, resulting in long-term problems of response delay and resource waste in industrial control systems. SUMMARY

[0003] (I) Technical problems solved To solve the problems of the prior art, the present application provides an industrial control data processing system and method based on an embedded real-time operating system, which solves the problem of how to realize real-time collaborative optimization of task scheduling and resource allocation in a dynamic load environment to simultaneously ensure low-latency response and high resource utilization of the system.

[0004] (II) Technical solutions To achieve the above purpose, the present application is implemented by the following technical solutions: an industrial control data processing system based on an embedded real-time operating system, comprising: The dynamic weight evaluation module, the resource elasticity allocation module and the double self-healing verification module; The dynamic weight evaluation module is used for generating a dynamic weight value according to a task type, a data security level, a deadline margin and a historical execution abnormality rate. The resource elasticity allocation module comprises a virtual resource elasticity pool and a load prediction engine, the virtual resource elasticity pool abstracts CPU computing power, memory blocks and I / O channels into virtual units that can be dynamically divided, and the load prediction engine predicts a future load peak value based on sliding window time series analysis and a lightweight LSTM network and generates a resource pre-allocation instruction. The double self-healing verification module comprises a pre-execution sandbox unit and a runtime error correction unit, the pre-execution sandbox unit detects potential deadlock loops of a task resource occupation path through a directed acyclic graph traversal algorithm, and the runtime error correction unit triggers a reverse tracing mechanism when a task is not completed twice in succession. The output end of the dynamic weight evaluation module is in communication connection with the input end of the resource elasticity allocation module, and the output end of the resource elasticity allocation module is in communication connection with the input end of the double self-healing verification module, forming a closed-loop scheduling link.

[0005] Preferably, in the dynamic weight evaluation module: The task type comprises a periodic task and a non-periodic task, and the data security level is divided into a safety instruction, a regular instruction and a low-priority instruction according to an industrial control safety standard. The deadline margin is calculated through a ratio of a remaining execution time window to a total duration of a task, and the historical execution abnormality rate is counted based on a number of timeouts or failures in a historical execution record of the task. The dynamic weight value is generated through fusion of four-dimensional parameters by a nonlinear normalization algorithm and is refreshed every millisecond.

[0006] Preferably, in the resource elasticity allocation module: 10% of elastic redundancy units are reserved in total resources of the virtual resource elasticity pool, and the elastic redundancy units are used for responding to burst tasks. High-weight tasks are preferentially bound to high-computing virtual units, and low-weight tasks share remaining virtual units through a time slice rotation mechanism. The prediction time window of the load prediction engine is 5 ms, and the prediction model parameters are dynamically adjusted according to historical load data.

[0007] The resource elastic allocation module abstracts physical resources into dynamically divisible virtual units, including CPU computing power units, memory blocks, and I / O channels. The load prediction engine predicts future short-term resource requirements based on a sliding window analysis of historical load data, and uses a lightweight neural network to identify load fluctuation patterns. When a sudden task or load peak is predicted, the elastic redundant units in the virtual resource elastic pool are activated, and high-weight tasks are preferentially allocated high-computing power resource combinations. Low-weight tasks use a time slice rotation mechanism to share the remaining resources. The length of the time slice is dynamically adjusted according to the real-time load level, including: using long-cycle time slices to increase throughput when the load is low, switching to short-cycle time slices and enabling a preemption mechanism when the load is high. If the actual load deviates from the predicted value beyond the tolerance range, the system automatically corrects the prediction model parameters and adjusts the proportion of elastic redundant units.

[0008] Preferably, the pre-execution sandbox unit performs the following operations: Before tasks are loaded into the scheduling queue, simulate the task resource occupation path and the dependencies between tasks; If a deadlock loop is detected, the dynamic weight values ​​of the conflicting tasks are automatically downgraded and the resource allocation path is reconstructed; The reconstructed resource allocation path avoids the virtual units occupied by conflicting tasks.

[0009] Preferably, the runtime error correction unit performs the following operations: When a task is not completed within the time window specified by the dynamic weight value twice in a row, the reverse tracing mechanism is triggered; Analyze the virtual unit map and scheduling logs occupied during task execution, dynamically modify weight function parameters or isolate abnormal virtual units; The corrected weight function parameters are updated to the dynamic weight evaluation module in real time.

[0010] Preferably, in the dual self-healing verification module: The output of the pre-execution sandbox unit is connected to the input of the runtime error correction unit to form a priori-posteriori collaborative mechanism; The a priori-posteriori collaborative mechanism associates pre-verification results with runtime exception data to dynamically optimize the model parameters of the load prediction engine.

[0011] The dual self-healing verification module performs risk prediction and anomaly repair before task scheduling and after execution. In the pre-execution phase, the system simulates the task resource occupancy path, constructs a dependency graph between tasks, and detects potential deadlock loops through a graph traversal algorithm. If a closed-loop dependency is found, the dynamic weight values ​​of the conflicting tasks are compared, the resource request priority of the low-weight task is downgraded, and the allocation path is reconstructed. During the execution of a task, if it is not completed within the specified time window twice in a row, the runtime error correction unit analyzes the virtual unit occupancy graph and scheduling log to trace the root cause of the delay, including: if it is caused by resource competition, the abnormal virtual unit is isolated and its subsequent allocation is restricted; if it is caused by inaccurate weight calculation, the historical anomaly rate statistical model is corrected and the weight value is refreshed. The corrected parameters are fed back to the dynamic weight evaluation module in real time to form a closed-loop optimization.

[0012] Preferably, in the time slice rotation mechanism: Low-weight tasks are sorted by dynamic weight values ​​and allocated time slices of the same virtual unit in sequence; The length of each time slice is dynamically adjusted according to the current system load status, and the adjustment range is 10μs to 200μs.

[0013] Preferably, the dynamic weight evaluation module, resource elastic allocation module and dual self-healing verification module are integrated into the kernel layer of the embedded real-time operating system, and directly call the physical resources of the CPU, memory and I / O through the hardware abstraction layer. The kernel layer directly operates the physical resources through the hardware abstraction layer to achieve dynamic mapping of computing power units, permission isolation of memory blocks and priority routing of I / O channels. When a hardware anomaly is detected, such as CPU overheating or memory failure, the elastic allocation module automatically downgrades the computing power of the faulty unit and reallocates tasks to healthy resources. In the collaborative process of self-healing mechanism and resource allocation, the system uses atomic operations to ensure data consistency under multi-core concurrency and avoid priority inversion problems.

[0014] The industrial control data processing method based on the embedded real-time operating system is implemented using the industrial control data processing system based on the embedded real-time operating system, and includes the following steps: S1: collects task attributes and real-time load status; S2: Generate dynamic weight values ​​according to four-dimensional parameters and refresh; S3: Pre-allocate virtual units to task queues based on load prediction results; S4: Reconstruct the resource path of the conflicting task through pre-execution sandbox verification; S5: Schedule task execution and trigger the runtime reverse error correction mechanism; S6: Update the weight function parameters and resource allocation strategy based on the error correction results.

[0015] Preferably, in the runtime reverse error correction mechanism: If a task is not completed twice in a row, the virtual unit it occupies will be isolated and marked as an abnormal unit; The abnormal unit is prohibited from being allocated in the subsequent three scheduling cycles until the parameter correction and function verification are completed.

[0016] At the method implementation level, the industrial control data processing system based on the embedded real-time operating system periodically executes the following processes, including: collecting task attributes and load status, calculating dynamic weights, predicting resource requirements, pre-verifying resource paths, scheduling task execution, monitoring execution status and triggering error correction. During the exception handling stage, isolated virtual units must undergo multi-cycle progressive testing before they can be reactivated. Hardware-level failure events trigger cross-layer alarms and permanently block the faulty units. All configuration parameters and correction records are stored in non-volatile memory to support version rollback and audit traceability. Through the deep coupling of dynamic weights and elastic resources, and the closed-loop linkage of load prediction and self-healing mechanisms, the core contradiction of balancing real-time performance and resource efficiency under dynamic load environments in industrial control scenarios is resolved, breaking through the limitations of traditional static scheduling strategies.

[0017] (3) Beneficial effects The present invention provides an industrial control data processing system and method based on an embedded real-time operating system. It has the following beneficial effects: (1) This industrial control data processing system and method based on an embedded real-time operating system uses a dynamic weight assessment module to quantify task criticality in real time, combined with load prediction-driven elastic resource allocation, to improve the real-time response capability and resource utilization efficiency of the industrial control system. The dynamic weight mechanism ensures that urgent tasks can instantly seize resources, avoiding the blocking problem of low-priority tasks caused by traditional static priority scheduling; the elastic resource pool dynamically adjusts the distribution of virtual units based on load fluctuation prediction, reducing task queuing delays during high-load periods and lowering resource idle rates during low-load periods. The dual self-healing verification module, through a dual-channel design of pre-execution sandbox detection and runtime error correction, effectively avoids execution failures caused by resource contention deadlocks and weight misjudgments, ensuring the stable operation of the system in a dynamic industrial environment.

[0018] (2) This industrial control data processing system and method based on an embedded real-time operating system deeply couples load perception, elastic resource allocation, and self-healing mechanisms to form a closed-loop optimization link. Compared with existing technologies, the system can reduce task scheduling delays, improve resource utilization, and reduce the incidence of deadlock events to near zero without increasing hardware redundancy. Its kernel-level integrated design ensures atomic control of physical resources, supports the deployment of industrial equipment across hardware platforms, and reduces the cost of production line upgrades. In addition, the dynamic parameter correction and abnormal unit isolation strategy driven by the self-healing mechanism reduce the frequency of manual operation and maintenance intervention, providing a highly reliable and highly adaptive real-time data processing solution for industrial control scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Figure 1 It is a schematic diagram of the overall framework of the present invention; Figure 2 This is a control logic timing diagram of the present invention. DETAILED DESCRIPTION

[0020] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0021] See also Figure 1 and Figure 2 The present invention provides a technical solution: an industrial control data processing system based on an embedded real-time operating system, comprising: Dynamic weight assessment module, resource elastic allocation module and dual self-healing verification module; The dynamic weight evaluation module is used to generate dynamic weight values ​​based on task type, data security level, deadline margin and historical execution exception rate; during the operation of the industrial control data processing system, the dynamic weight evaluation module continuously collects task attribute information in the embedded real-time operating system, including task type, data security level, deadline margin and historical execution exception rate; among them, task types include periodic tasks and non-periodic tasks, periodic tasks include sensor data collection, and non-periodic tasks include equipment abnormal shutdown instructions; data security levels are divided into safety-critical instructions, routine control instructions and low-priority monitoring instructions according to industrial safety protocols; deadline margin is dynamically updated by calculating the ratio of the remaining executable time of the task to the total duration in real time; historical execution exception rate is the frequency of timeout or failure of the task in the past execution cycle.

[0022] The above four types of parameters are processed through nonlinear normalization to generate dynamic weight values, including: for non-periodic tasks, if their data security level is safety-critical instructions and the deadline margin is lower than the preset threshold, such as the remaining time ratio is less than 20%, the weight value will be triggered to increase exponentially; when the historical execution exception rate exceeds the set upper limit, the weight value will be linearly decayed to reduce its resource preemption priority. The dynamic weight value is refreshed every millisecond to ensure that urgent tasks, such as sudden fault instructions, can instantly jump to the high-priority queue. Based on the dynamic weight value sorting results, the resource elastic allocation module allocates 10% of the elastic redundant units reserved in the virtual resource elastic pool to high-weight tasks first, and the remaining tasks are allocated the remaining resources using a dynamic time slice rotation mechanism in descending order of weight value. When the load prediction engine detects that a load peak will occur within the next 5ms, it switches the elastic redundant units to the standby state in advance to avoid task queuing delays.

[0023] The dual self-healing verification module simulates the resource occupation path of a task before loading it. If it detects that the dependency relationship between tasks forms a loop conflict, it automatically downgrades the weight value of the conflicting task to a low priority range and replans the resource allocation path. If a task fails to be completed within the time window specified by the dynamic weight for two consecutive times during execution, the reverse tracing mechanism is triggered to analyze the virtual unit map and scheduling log occupied by it, dynamically correct the weight calculation parameters or isolate abnormal resource units, and the correction results are fed back to the dynamic weight evaluation module in real time to form a closed-loop optimization.

[0024] The resource elasticity allocation module includes a virtual resource elastic pool and a load prediction engine. The virtual resource elastic pool abstracts CPU computing power, memory blocks, and I / O channels into dynamically divisible virtual units. The load prediction engine predicts future load peaks and generates resource pre-allocation instructions based on sliding window time series analysis and a lightweight LSTM network. During the resource elasticity allocation process of the industrial control data processing system, the virtual resource elastic pool abstracts physical resources into dynamically divisible virtual units. Each virtual unit adjusts its capacity and distribution in real time based on the current system load status. Physical resources include CPU computing power, memory blocks, and I / O channels.

[0025] When the system is under low load, virtual units are segmented at the smallest granularity to reduce resource fragmentation. When the load prediction engine detects a possible load peak within the next 5ms based on sliding window time series analysis, the lightweight LSTM network predicts the incremental resource demand based on historical load fluctuation patterns and triggers the dynamic aggregation of virtual units. This means merging adjacent small-granularity units into high-computing-power units to reserve resources for upcoming high-weight tasks. The sliding window time series refers to the load data with a window length of the most recent 50ms.

[0026] If the prediction result is a burst task, such as a surge in sensor data streams, the 10% elastic redundant units reserved in the virtual resource elastic pool will be called first to ensure that high-weight tasks can be immediately bound to high-computing resources; for low-weight tasks, the resource allocation module sorts the results according to the real-time weight values ​​and uses a dynamic time slice rotation mechanism to allocate the remaining virtual units. The time slice length is adjusted inversely with the current load level, including: when the load is less than 50%, long-cycle time slices are allocated to increase throughput; when the load is above 80%, short-cycle time slices are switched to reduce latency; among them, the long-cycle time slice is 200μs and the short-cycle time slice is 10μs.

[0027] When actual load deviates from the predicted value by more than 15%, the load prediction engine automatically triggers model parameter corrections. These include increasing the sliding window length to improve data coverage if actual load exceeds the predicted value; and reducing the number of hidden layer nodes in the LSTM network to reduce computational overhead if actual load consistently falls short of the predicted value. Resource pre-allocation instructions are generated every millisecond and synchronized in real time with the output of the dynamic weight evaluation module, ensuring that high-weight tasks always receive priority access to virtual unit combinations that match their criticality, such as high-computing CPU units, contiguous memory blocks, and exclusive I / O channels.

[0028] The dual self-healing verification module consists of a pre-execution sandbox unit and a runtime error correction unit. The pre-execution sandbox unit uses a directed acyclic graph traversal algorithm to detect potential deadlock loops in task resource usage paths. The runtime error correction unit triggers a backtracking mechanism if a task fails to complete twice in a row. During the self-healing verification process for an industrial control data processing system, the pre-execution sandbox unit simulates the resource usage paths and inter-task dependencies before loading tasks into the scheduling queue. This involves abstracting tasks as nodes in a directed acyclic graph, defining resource usage relationships as directed edges between nodes, and detecting loops using a depth-first traversal algorithm. If a closed-loop dependency is detected between task nodes—for example, if task A occupies resource X and then requests resource Y, while task B already occupies resource Y and is waiting for resource X—a deadlock risk is identified. At this point, the system automatically compares the dynamic weights of the conflicting tasks, relegating lower-weight tasks to a non-blocking queue, and reconfiguring the resource allocation path, prioritizing high-weight tasks to independent virtual units and shifting lower-weight tasks to shared resource channels.

[0029] When actual load fluctuations cause deviations in the prediction model, the runtime error correction unit monitors the execution status of tasks. This includes: If a task fails to complete within the time window specified by the dynamic weight value twice in a row—for example, if the deadline margin has been exhausted but the task is still running—then a reverse tracing mechanism is triggered, extracting the virtual unit map and scheduling logs occupied during the task's execution to analyze the root cause of the delay. If the delay is caused by resource contention, the abnormal virtual unit is isolated and marked as disabled. If the priority is misjudged due to inaccurate weight calculation parameters, the historical execution exception rate weight coefficient in the weight function is dynamically adjusted to reduce the impact of past occasional exceptions on the current task.

[0030] After the self-healing operation is complete, the system synchronizes the corrected parameters to the dynamic weight assessment module and removes the isolation mark for the abnormal unit. However, the unit can only be allocated to non-critical tasks in the next three scheduling cycles until it passes functional verification. For temporary deadlocks caused by sudden load changes, the pre-execution sandbox unit automatically skips the virtual units occupied during the current load peak when reconstructing the resource path and reserves buffer resource blocks for subsequent tasks to avoid chain blockages. This self-healing process is linked in real time with the resource elastic allocation module, forming a closed-loop optimization mechanism of "prediction-execution-verification-correction."

[0031] The output of the dynamic weight assessment module is connected to the input of the resource elastic allocation module, which is in turn connected to the input of the dual self-healing verification module, forming a closed-loop scheduling link. In the closed-loop scheduling link of the industrial control data processing system, the dynamic weight value of the task generated in real time by the dynamic weight assessment module is transmitted to the input of the resource elastic allocation module via the communication interface, triggering the generation of resource pre-allocation instructions. When the system is in steady-state operation, the resource elastic allocation module binds high-computing power units in the virtual resource elastic pool to high-priority tasks based on the weight value sorting results, and periodically sends a resource allocation map to the dual self-healing verification module; if the load prediction engine detects that a sudden task will occur within the next 5ms, such as an emergency stop command for the production line, the dynamic weight assessment module immediately increases the weight value of the relevant task to the critical threshold, and the resource elastic allocation module synchronously calls the elastic redundancy unit to ensure that high-priority tasks skip the regular queue and directly obtain resources.

[0032] When the task enters the execution phase, the dual self-healing verification module verifies the security of the resource path through the pre-execution sandbox unit, including: if a deadlock loop is detected, a path reconstruction request is sent to the resource elastic allocation module to forcibly release the virtual units occupied by the conflicting tasks and reallocate them; if the task fails to execute twice in a row due to insufficient resources or weight misjudgment, the runtime error correction unit transmits the abnormal data back to the dynamic weight evaluation module, triggering the online correction of the weight function parameters. For example, when a safety-critical task is underestimated due to an excessively high historical abnormality rate, the system automatically reduces the weight coefficient of the historical abnormality rate and immediately refreshes the dynamic weight value of the task; among them, the abnormal data includes virtual unit occupancy records and weight calculation parameters.

[0033] The revised parameters take effect in real time through the closed-loop link. This includes: the new weight values ​​drive the resource elastic allocation module to adjust the virtual unit binding strategy, and the updated resource allocation map re-enters the self-healing verification process, forming a continuous optimization cycle of "evaluation-allocation-verification-feedback." When the system load fluctuates drastically, such as when the load peak exceeds the predicted value by 15%, the closed-loop link activates emergency mode, including: the dynamic weight evaluation module temporarily freezes the weight refresh of non-critical tasks, the resource elastic allocation module switches all elastic redundant units to high-computing mode, and the dual self-healing verification module skips pre-execution sandbox detection to reduce latency, prioritizes the execution integrity of core control instructions, and automatically resumes full-function closed-loop scheduling after the load drops.

[0034] In the dynamic weight evaluation module: Task types include periodic tasks and non-periodic tasks. Data security levels are divided into security instructions, regular instructions, and low-priority instructions according to industrial control security standards. The deadline margin is calculated by the ratio of the remaining execution time window to the total duration of the task. The historical execution exception rate is based on the number of timeouts or failures in the task's historical execution records. The dynamic weight value is generated by fusing four-dimensional parameters through a nonlinear normalization algorithm and is refreshed every millisecond.

[0035] It should be further explained that, in the specific implementation process, during the dynamic weight evaluation process of the industrial control data processing system, task attribute information is collected in real time through the kernel interface of the embedded real-time operating system, including: for periodic tasks, such as sensor calibration instructions executed every 50ms, the system automatically marks its task type and associates it with the preset data security level; non-periodic tasks dynamically divide the data security level according to the source of the instruction; among them, non-periodic tasks include equipment abnormal shutdown requests, and the instruction source includes the safety controller or the general monitoring module.

[0036] Deadline margin is calculated by monitoring the difference between the actual execution time of a task and the preset total duration in real time. If the remaining time falls below 20%—for example, if a 100ms task has not completed for 80ms—a deadline margin warning flag is triggered, which serves as a reinforcement factor in weight calculation. Historical execution exception rate statistics are calculated based on a sliding window, which defaults to the most recent 10 execution records. If a task experiences more than three timeouts or failures within the window, its exception rate is considered excessive and a weight decay mechanism is initiated: the weight decreases linearly by 10% with each additional exception record. To generate dynamic weights, the four parameters are nonlinearly normalized. For safety-critical instruction tasks, the data security level parameter holds the dominant weight, accounting for 50%, followed by the deadline margin, accounting for 30%. When a task enters the deadline warning state, the system automatically increases the margin parameter weight to 60%, while simultaneously reducing the weight of the historical exception rate to avoid misjudgment. The weight value is refreshed every millisecond. If a burst task is triggered, the current refresh cycle is immediately interrupted, the task's weight is forced to be raised to the preset highest priority threshold, and its resource allocation path is locked for at least 5ms to ensure execution integrity. The refreshed weight value is transmitted to the resource elastic allocation module via the shared memory area and is simultaneously backed up to non-volatile memory for traceability analysis by the runtime error correction unit. Burst tasks include production line emergency stop signals.

[0037] In the resource elastic allocation module: 10% of the total resources in the virtual resource elastic pool are reserved as elastic redundancy units, which are dedicated to responding to sudden tasks. High-weight tasks are preferentially bound to high-computing-power virtual units, while low-weight tasks share the remaining virtual units using a time-slice rotation mechanism. The load prediction engine has a prediction time window of 5ms and dynamically adjusts the prediction model parameters based on historical load data.

[0038] It should be further explained that, in the specific implementation process, in the resource elasticity allocation process of the industrial control data processing system, the virtual resource elastic pool will designate 10% of the total resources as elastic redundant units, which are only allowed to be enabled when sudden tasks or load mutations are detected.

[0039] When the load prediction engine predicts a possible load peak within the next 5ms based on sliding window time series analysis, the lightweight LSTM network dynamically adjusts the prediction model parameters according to historical load patterns. This includes: if the historical data shows periodic load fluctuations, the sampling density of the time series is increased to improve prediction accuracy; if the load fluctuations show random characteristics, the number of hidden layer nodes of the LSTM network is automatically increased to enhance the burst pattern recognition capability. Among them, load fluctuations include production line acceleration every 30 seconds, and random characteristics include instantaneous data surges caused by equipment failures.

[0040] For high-weight tasks, resource binding follows dynamic coupling rules, including: when the task weight value exceeds the preset threshold, high-computing power virtual units and continuous memory blocks are allocated first, and I / O channels are exclusively occupied to avoid transmission conflicts; if the system is in a high-load state, the elastic redundant unit automatically switches to high-computing power mode, temporarily merging scattered small-granularity units to meet task requirements. Among them, the high-computing power virtual unit includes aggregating two adjacent CPU units to form a dual-core computing power block. The high-load state is when the resource utilization rate exceeds 80%.

[0041] Low-weight tasks use a dynamic time-slice rotation mechanism to allocate remaining resources, including: when the system load is less than 50%, in order to improve throughput, the time slice length is set to 200μs, allowing a single task to continuously occupy resources to complete multi-stage operations; when the load rises to the range of 50% to 80%, the time slice is shortened to 100μs to balance efficiency and latency; if the load exceeds 80%, it is further compressed to 10μs and preemptive scheduling is enabled to ensure that high-weight tasks can interrupt low-priority tasks at any time.

[0042] When the actual load deviates from the predicted value by more than 15%, an adaptive correction mechanism is triggered. This includes: if the actual load exceeds the predicted value, the sliding window is expanded to 100ms to cover longer historical data, and the LSTM network weight parameters are reset. If the actual load continues to fall below the predicted value, the number of LSTM network layers is reduced to reduce computational overhead, and some elastic redundant units are released to the public resource pool. Resource pre-allocation instructions are generated every millisecond and strictly synchronized with the real-time weight values. For example, when a high-weight task fails to obtain the required virtual units due to insufficient elastic redundant resources, the system automatically downgrades its binding requirements, adjusting the dual-core computing power requirement to a single core, marking it as a task to be compensated, and prioritizing compensation resources in the next scheduling cycle.

[0043] The pre-execution sandbox unit performs the following operations: Before tasks are loaded into the scheduling queue, simulate the task resource occupation path and the dependencies between tasks; If a deadlock loop is detected, the dynamic weight values ​​of the conflicting tasks are automatically downgraded and the resource allocation path is reconstructed; The reconstructed resource allocation path avoids the virtual units occupied by conflicting tasks.

[0044] It should be further explained that in the specific implementation process, in the pre-execution verification stage of the industrial control data processing system, when a new task request is loaded into the scheduling queue, the pre-execution sandbox unit abstracts the task into a resource-occupying node and constructs a dependency graph between tasks based on its declared virtual unit requirements, where the virtual unit requirements include the number of CPU computing power blocks, memory capacity range and I / O channel type.

[0045] The system uses a depth-first search algorithm when traversing the graph. If it finds that resource requests between task nodes form a closed-loop path (for example, task A depends on the I / O channel released by task B, while task B is simultaneously waiting for the memory block occupied by task A), it determines that there is a risk of deadlock. At this time, the system automatically compares the dynamic weight values ​​of the conflicting tasks, including: if the weight difference between the conflicting parties exceeds 30%, the priority of the low-weight task is immediately downgraded to the non-blocking queue and an alternative resource path is assigned to it, such as changing the exclusive I / O channel to a shared channel; if the weight difference is between 10% and 30%, a buffer resource block is temporarily inserted and allocated from the elastic redundant unit, allowing the high-weight task to execute first but limiting its resource occupation time; if the weight difference is less than 10%, the virtual units occupied by both parties are forcibly released and reallocated to the conflict-free path.

[0046] During resource path reconstruction, the system prioritizes retaining the original resource binding scheme for high-weight tasks, while lower-weight tasks are repurposed to use a time-sharing, multiplexed resource pool and adding a conflict marker to their resource request headers. When load fluctuations lead to insufficient predicted resources, the pre-execution sandbox unit automatically skips virtual units occupied during the current peak load period, reserving at least two scheduling cycles of buffer resources for subsequent tasks. For example, 5% of elastic redundant units are prohibited from allocation.

[0047] For temporary loops caused by dynamic changes in task dependencies, such as the addition of a sensor data processing chain after a production line speed adjustment, the sandbox verification results trigger an emergency refresh mechanism in the dynamic weight evaluation module, forcing the weights of related tasks to be recalculated within 1ms and updating the resource allocation priority. After completing the path reconstruction, the system records the degradation history of conflicting tasks. If the same task triggers deadlock more than twice within three scheduling cycles, its resource request type is permanently restricted, and exclusive I / O channel requests may be prohibited. The reconstructed resource allocation map is synchronously transmitted to the runtime error correction unit along with real-time load data, serving as a reference for exception backtracking.

[0048] The runtime error correction unit performs the following operations: When a task is not completed within the time window specified by the dynamic weight value twice in a row, the reverse tracing mechanism is triggered; Analyze the virtual unit map and scheduling logs occupied during task execution, dynamically modify weight function parameters or isolate abnormal virtual units; The corrected weight function parameters are updated to the dynamic weight evaluation module in real time.

[0049] It should be further explained that during the specific implementation, during the runtime error correction phase of the industrial control data processing system, if a task fails to complete within the time window specified by the dynamic weight value twice in a row, the runtime error correction unit immediately intercepts the complete virtual unit occupancy map and scheduling log data packet of its execution cycle. The system first analyzes the task execution timeline. This includes: if the task times out due to resource contention during its first execution, such as a high-weight task preempting its bound I / O channel, the dynamic weight value of the occupier of the conflicting resource is traced. If the occupier's weight is at least 30% higher than that of the current task, it is determined to be a legitimate preemption. The system then isolates only the abnormal virtual units occupied by the current task, such as memory blocks that have been preempted multiple times, and marks them as prohibited from allocation for three scheduling cycles. If the difference in occupier weights is less than 30%, the weight function parameter correction is triggered. Specifically, the calculation weight ratio of the historical execution anomaly rate is reduced, and the priority coefficient of the deadline margin parameter is increased, so that similar tasks receive higher dynamic weight values ​​in subsequent scheduling.

[0050] For execution failures caused by inaccurate weight calculations, such as when a safety-critical task's weight is underestimated due to a high historical exception rate, the system extracts the task's execution records from the past five scheduling cycles. If the actual completion rate exceeds a preset threshold of 90%, the system smooths the historical exception rate statistical model. This includes increasing the time decay factor of timeout or failure records by 50% to reduce the weight of outdated exception data. The revised parameters take effect immediately, and new dynamic weights are generated in the next millisecond refresh cycle, driving the resource allocation module to rebind virtual units. If a task fails due to insufficient resources caused by load forecast deviations, the error correction unit forcibly uses reserved resources in the elastic redundant unit, temporarily increasing the task's virtual unit quota by an additional 10% of CPU power. These resources are then immediately released back to the elastic pool upon task completion. If the same virtual unit is marked as abnormal twice within three scheduling cycles, a hardware diagnostic process is triggered, including mapping the unit to a physical resource address, performing read and write verification tests, and, if the tests fail, sending a hardware fault alert to the operations and maintenance system and permanently disabling the unit at the software level.

[0051] The results of all corrections are fed back to the dynamic weight evaluation module via a closed-loop link and synchronously updated to the configuration backup area in non-volatile memory, ensuring that the optimized parameter logic is retained after the system restarts. For occasional failures caused by external interference, the system retains the original weight calculation logic after parameter correction but adds a mechanism to suppress abnormal fluctuations. Specifically, if the task completes normally within the next two cycles, the original parameter configuration is automatically restored. External interference includes sensor signal noise.

[0052] In the dual self-healing verification module: The output of the pre-execution sandbox unit is connected to the input of the runtime error correction unit to form a priori-posteriori collaborative mechanism; The a priori-posteriori collaborative mechanism associates pre-verification results with runtime exception data to dynamically optimize the model parameters of the load prediction engine.

[0053] It should be further explained that, during the specific implementation process, during the self-healing collaborative optimization of the industrial control data processing system, the resource path verification results generated by the pre-execution sandbox unit and the abnormal execution data captured by the runtime error correction unit are linked in real time through a shared memory area. This includes: when a task marked as low-risk in the pre-verification phase triggers two consecutive timeouts during actual execution, the system automatically compares the load prediction value during pre-verification with the actual load curve during runtime. If the deviation exceeds 15% and persists for more than three scheduling cycles, it is determined that the load prediction model has a steady-state error. At this time, the a priori-posteriori collaborative mechanism activates the model compensation strategy, namely: for periodic load fluctuation scenarios, the sampling length of the sliding window time series is extended to 100ms to cover the complete cycle characteristics; for sudden load spikes, the number of hidden layer nodes in the lightweight LSTM network is increased and recent abnormal data is injected as training samples.

[0054] When no deadlock is detected in the pre-verification phase but resource contention occurs during runtime, the system traces the historical dynamic weight values ​​of the conflicting tasks in the pre-verification phase. If it is found that the weight value has mutated within 5ms before the task is loaded, such as the weight jump is triggered by an external instruction, the system will force the addition of weight stability checks for such tasks in the subsequent pre-verification process, including: before the task is loaded, the weight fluctuation range must be maintained within 10% for at least 2ms, otherwise it will be downgraded to the buffer queue for secondary verification.

[0055] For inconsistencies between pre-verification and runtime states caused by dynamic changes in dependency relationships, the collaborative mechanism performs a difference analysis between the actual dependency graph between tasks captured at runtime and the simulated graph in the pre-verification phase. If the number of newly added dependency edges exceeds the preset threshold, such as more than three new dependencies for a single task, a hot update of the pre-verification model is triggered, i.e., the initial node selection strategy of the directed acyclic graph traversal algorithm is reset, and detection is prioritized from high-weight task nodes to reduce the missed detection rate.

[0056] The optimized load prediction parameters and pre-verification rules take effect in real time through kernel-level interrupt service routines, with three historical versions retained in non-volatile memory. If the new parameters cause resource utilization to drop by more than 20% over two consecutive scheduling cycles, the system automatically rolls back to the previous stable version and triggers a manual intervention alert. During the collaborative optimization process, the dynamic proportion of elastic redundant units is adjusted based on the a priori-posteriori error rate. This includes maintaining a baseline of 10% when the error rate is below 5%, increasing it to 15% when the error rate is between 5% and 15% to enhance the ability to cope with sudden loads, and initiating a cross-node resource loan mechanism if the error rate exceeds 15%, such as temporarily migrating virtual units from idle compute nodes, until the error rate returns to a controllable range.

[0057] In the time slice rotation mechanism: low-weight tasks are sorted by dynamic weight values ​​and allocated time slices of the same virtual unit in turn; the length of each time slice is dynamically adjusted according to the current system load status, with an adjustment range of 10μs to 200μs. It should be further explained that, in the specific implementation process, during the dynamic time slice scheduling of the industrial control data processing system, the low-weight task queue is sorted according to the dynamic weight value refreshed in real time, and the resource allocation module adaptively adjusts the time slice length according to the current system load level, including: when the load monitor detects that the combined utilization of CPU and memory is less than 50%, the time slice is set to a 200μs long cycle mode, allowing low-weight tasks to continuously execute multi-stage operations, such as batch sensor data preprocessing, while disabling the task preemption mechanism to improve throughput; if the load rises to the range of 50% to 80%, it switches to a 100μs balanced mode, and inserts a 5μs scheduling gap at the end of each time slice for high-weight tasks to check resource preemption requirements; when the load exceeds the 80% critical value, the time slice is compressed to a 10μs short cycle mode, and a forced preemption strategy is enabled, that is, if a high-weight task arrives during the time slice execution, the current low-weight task is immediately interrupted and its context state is retained.

[0058] The time slice length adjustment follows the hysteresis buffer principle, including: when the load rises from the low range to the medium range, delaying two scheduling cycles before switching modes to avoid frequent oscillations; when the load drops by more than 20%, if the burst task is completed, the long cycle mode is immediately restored to speed up the processing of backlog tasks. For low-weight tasks with a historical execution exception rate higher than 30%, the system imposes an additional time slice penalty mechanism, including: the length of its time slice is reduced to 50% of the normal value in the same load range, and the occupied virtual units are forcibly released when two consecutive time slices are not completed. When virtual unit fragmentation is detected during the time slice rotation process, if the remaining memory block is smaller than the task requirement, a dynamic aggregation operation is triggered, including: merging adjacent idle virtual units into continuous blocks, and giving priority to low-weight tasks with a higher ranking.

[0059] The execution status of time slices is recorded in real time in the scheduling log. If the same task fails to complete due to insufficient resources within three consecutive time slices, a temporary weight increase mechanism is triggered. This means that its dynamic weight is increased to the upper limit of the current interval, and a high-computing virtual unit is allocated in the next scheduling cycle. The time slice adjustment parameters are linked to the load forecast results. For example, when the load forecast engine determines that a high load state will be reached within the next 5ms, a time slice decrement warm-up is initiated three scheduling cycles in advance, such as gradually reducing the time slice from 200μs to 80μs, to avoid scheduling delays caused by sudden load changes. Time slice allocation anomalies will trigger the runtime error correction unit to intervene, forcibly reclaiming resources and marking the relevant virtual units as abnormal. Among them, time slice allocation anomalies include time slice timeouts with no resource release.

[0060] The dynamic weight assessment module, resource elasticity allocation module, and dual self-healing verification module are integrated into the kernel layer of the embedded real-time operating system and directly access the physical resources of the CPU, memory, and I / O through the hardware abstraction layer. It should be further explained that in the specific implementation process, within the kernel layer integrated architecture of the industrial control data processing system, the dynamic weight assessment module, resource elasticity allocation module, and dual self-healing verification module are directly embedded in the kernel space of the embedded real-time operating system, performing atomic-level operations on physical resources through the hardware abstraction layer.

[0061] When the system is initialized, the hardware abstraction layer maps the computing power of the CPU core into quantifiable computing units. For example, the basic computing power of a single core is 1U, and the overclocking mode is 1.5U. The physical address space of the memory is divided into continuous blocks and the access rights are marked. For example, the memory area exclusively used by security-critical tasks is prohibited from being written by low-weight tasks. The I / O channels are classified into high-speed channels and low-speed channels according to the transmission rate and priority. Among them, the high-speed channel is used for real-time sensor data streams, and the low-speed channel is used for log transmission.

[0062] The kernel layer captures task execution events in real time through the hardware abstraction layer's interrupt controller. This includes: When a high-weight task triggers an emergency interrupt, such as a production line emergency stop signal, the dynamic weight assessment module directly hijacks the current scheduling process in kernel state, forcibly refreshes the weight value, and invokes the resource elastic allocation module's atomic operation interface, switching the specified CPU core to overclocking mode and locking access rights to the associated memory block. If a memory out-of-bounds access is detected during task execution, the dual self-healing verification module captures the abnormal address through the hardware abstraction layer's memory management unit (MMU), immediately isolates the faulty memory page, and remaps it to a backup virtual unit, while simultaneously submitting the abnormal event to the security audit module.

[0063] The hardware abstraction layer's unified encapsulation of heterogeneous computing units enables the resource elastic allocation module to dynamically divide virtual units across hardware platforms. This includes: in scenarios with hardware accelerators, high-weight tasks can be bound to dedicated acceleration units, while general computing tasks are still handled by CPU virtual units; among them, heterogeneous computing units can be FPGA accelerators; high-weight tasks are bound to dedicated acceleration units, that is, matrix operation instructions are routed to the FPGA.

[0064] When the system load exceeds the physical resource limit, the kernel layer triggers a hardware-level degradation strategy, including dynamically shutting down non-critical peripherals to free up I / O channel resources and forcing low-weight tasks into a sleep queue until the load drops. Non-critical peripherals include debug interfaces.

[0065] The hardware abstraction layer also provides physical resource health monitoring. For example, if a CPU core temperature exceeds a safety threshold for three consecutive scheduling cycles, the elastic allocation module automatically marks its computing unit as degraded (downgraded from 1U to 0.7U), prioritizing cooling time slices in subsequent scheduling. All kernel-level operations utilize a lock-free design, using memory barrier instructions to ensure data consistency across multiple cores and avoid priority inversion issues caused by spin locks.

[0066] The industrial control data processing method based on the embedded real-time operating system is implemented by an industrial control data processing system based on the embedded real-time operating system, and includes the following steps: S1: collects task attributes and real-time load status; S2: Generate dynamic weight values ​​according to four-dimensional parameters and refresh; S3: Pre-allocate virtual units to task queues based on load prediction results; S4: Reconstruct the resource path of the conflicting task through pre-execution sandbox verification; S5: Schedule task execution and trigger the runtime reverse error correction mechanism; S6: Update the weight function parameters and resource allocation strategy based on the error correction results.

[0067] It should be further explained that, in the specific implementation process, during the execution of the industrial control data processing method, the system first collects task attribute information through the kernel interface of the embedded real-time operating system, including: for periodic tasks, such as multi-axis position calibration performed every 100ms, automatically identifying its task type and associating it with a preset data security level label; for non-periodic tasks, such as equipment temperature over-limit alarm, the security level is dynamically divided according to the security certification level of the hardware module from which the instruction comes.

[0068] The real-time load status monitoring module synchronously collects CPU computing power usage, memory remaining block distribution and I / O channel congestion index, and compresses and encapsulates the data before transmitting it to the dynamic weight calculation engine.

[0069] During the weight generation phase, the system performs a nonlinear fusion of four-dimensional parameters. This includes: When a task is a safety-critical instruction with a deadline margin less than 20%, the weight coefficient of the data security level parameter is forcibly increased to 70%, ignoring the impact of historical execution exception rates. If the task's historical exception rate exceeds 30% and no exceptions have occurred in the last three scheduling cycles, a decay compensation algorithm is activated, shortening the exception rate statistics window to the last five execution records to reduce historical interference. The refreshed dynamic weight values ​​are transmitted to the resource allocation module every millisecond via a memory-mapped channel and are also backed up in a non-volatile storage area with a checksum.

[0070] During the resource pre-allocation phase, the load prediction engine predicts resource demand within the next 5ms based on sliding window time series data. The sliding window length is dynamically adjusted to an integer multiple of the most recent load fluctuation period. If a sudden task peak is predicted, the distributed units in the virtual elastic pool are merged in advance to form a high-computing power block, and 10% of the elastic redundant units are switched to a pending state.

[0071] Pre-execution sandbox verification simulates the resource usage path of tasks before they are loaded. If a task dependency loop is detected, the weight difference between conflicting tasks is compared. If the difference exceeds 30%, the resource request priority of the lower-weight task is directly downgraded. If the difference is less than 10%, buffer resources are inserted and the occupancy duration of the higher-weight task is limited. During task scheduling, a dynamic time-slicing rotation strategy is implemented. When the system load is below 50%, low-weight tasks are allowed to continuously occupy 200μs time slices. When the load exceeds 80%, a 10μs preemptive time slice is enabled to ensure that high-priority tasks can be interrupted immediately.

[0072] The runtime error correction mechanism triggers reverse tracing after two consecutive task timeouts, including: analyzing the virtual unit occupancy map. If the failure is caused by resource competition, the abnormal unit is isolated for three scheduling cycles; if the failure is caused by inaccurate weight parameters, the attenuation factor of the historical abnormality rate is corrected and the weight value is refreshed immediately. During the parameter update phase, all correction results are fed back to the weight calculation engine through a closed-loop link and take effect in the next millisecond cycle. When a sudden change in external load causes a continuous deviation in the prediction model, the system automatically extends the sliding window to 150ms and resets the LSTM network nodes, while increasing the elastic redundancy ratio to 15% to maintain scheduling stability. Abnormal events generated during the execution of the method trigger a cross-layer alarm mechanism, including: gradually downgrading non-critical tasks within three scheduling cycles until the system enters a safe fault-tolerant mode to ensure the execution integrity of core control instructions. Abnormal events include hardware resource failures.

[0073] In the runtime reverse error correction mechanism: If a task is not completed twice in a row, the virtual unit it occupies will be isolated and marked as an abnormal unit; The abnormal unit is prohibited from being allocated in the subsequent three scheduling cycles until the parameter correction and function verification are completed.

[0074] It should be further explained that, in the specific implementation process, in the runtime reverse error correction mechanism of the industrial control data processing method, when a task is not completed twice in a row within the time window specified by the dynamic weight value, the system immediately freezes the virtual unit occupied by the task, marks it as an abnormal unit and generates an isolation instruction, including: the abnormal unit is prohibited from being reallocated within the next three complete scheduling cycles, during which only read-only verification operations are allowed, such as checksum comparison of memory blocks or signal integrity testing of I / O channels.

[0075] After the isolation operation is completed, the system extracts the virtual unit occupancy map and weight value change records of the task in the past five scheduling cycles, and analyzes the root cause of the delay, that is: if the failure is caused by resource competition, such as a high-weight task preempting its bound CPU computing power unit multiple times, the dynamic weight history value of the preempting party is traced, including: when the preempting party's weight value has undergone a non-preset mutation during the execution of the task, such as an external instruction forcibly increasing the weight by more than 50%, it is determined to be an abnormal preemption event. The system automatically locks the weight calculation parameters of the preempting party's task to static mode, freezes the dynamic update of the historical abnormality rate and deadline margin, and adds an over-occupancy penalty to its resource request in the next scheduling cycle, such as limiting the number of virtual units it can apply for to 80% of the normal value.

[0076] If the task failure is due to inaccurate weight calculation, for example, the weight value of a safety-critical task is underestimated due to historical sporadic anomalies, the parameter compensation mechanism will be activated, including: applying a time decay factor to the historical anomaly rate statistical model, that is, reducing the weight of anomaly records more than three scheduling cycles ago by 70%, and increasing the coefficient ratio of the data security level parameter to 60%. The corrected parameters take effect immediately and generate new dynamic weight values.

[0077] For resource shortages caused by load forecast deviations, the system calls on the reserved resources in the elastic redundant unit to temporarily compensate the task. The compensation amount is 120% of the original allocation. For example, if 2 CPU virtual units were originally allocated, 0.4 units will be added, and the excess will be recovered immediately after the task is completed. If the same virtual unit is marked as abnormal more than three times within a cumulative five scheduling cycles, the hardware mapping diagnostic process will be triggered, including: binding it to the physical resource address through the hardware abstraction layer, such as the memory slot B1 channel, performing a stress test, including continuous writing / reading of specific data patterns. If the test failure rate exceeds 5%, a hardware replacement alarm will be sent to the operation and maintenance terminal, and the physical unit will be permanently blocked at the software level, and its capacity will be removed from the virtual resource pool.

[0078] The results of all correction operations are synchronized in real time to multiple backup areas of non-volatile memory, and a version difference log is generated to record the impact of parameter changes on the scheduling success rate of similar tasks before and after. After the abnormal unit completes three cycles of isolation, the system performs a progressive recovery test on it at the beginning of the fourth scheduling cycle, including: the first assignment to a non-critical low-weight task, such as a logging instruction. If the task is successfully completed, 50% of the available capacity will be restored; the second assignment to a regular task, if successful, the isolation mark will be completely removed. If the exception is triggered again during the test, the isolation period will be extended to five scheduling cycles and upgraded to a hardware-level failure event. All resource adjustment instructions generated during the error correction process are implemented through atomic operations to ensure that state inconsistencies do not occur under high concurrent loads.

[0079] During the implementation of an industrial control data processing system based on an embedded real-time operating system, the system's core modules include a dynamic weight assessment module, a resource elasticity allocation module, and a dual self-healing verification module. These three modules operate collaboratively through a closed-loop link at the embedded kernel layer. The dynamic weight assessment module collects real-time attribute information such as task type, data security level, deadline margin, and historical execution anomaly rate. Task types are categorized as periodic or non-periodic. Data security levels are divided into multiple tiers based on industrial control security standards. The deadline margin is determined by dynamically calculating the ratio of the remaining execution time window to the total execution time of the task in real time. The historical execution anomaly rate is based on the frequency of timeouts or failures in the task's historical execution records. These parameters are then nonlinearly normalized to generate dynamic weights. The data security level and deadline margin dominate the weighting coefficients, while the historical anomaly rate dynamically adjusts the weight based on the task's recent performance. The weights are updated at a millisecond frequency. When an emergency task is triggered, the current calculation cycle is immediately interrupted and the weight is raised to the preset highest priority threshold.

[0080] The dynamic weight assessment module quantifies task criticality in real time, combined with load prediction-driven elastic resource allocation, to improve the real-time responsiveness and resource utilization efficiency of industrial control systems. The dynamic weighting mechanism ensures that urgent tasks can instantly preempt resources, avoiding the blocking of low-priority tasks caused by traditional static priority scheduling. The elastic resource pool dynamically adjusts the distribution of virtual units based on predicted load fluctuations, reducing task queuing delays during high-load periods and lowering resource idleness during low-load periods. The dual self-healing verification module, through a dual-channel design of pre-execution sandbox detection and runtime error correction, effectively avoids execution failures caused by resource contention deadlocks and weight misjudgments, ensuring stable system operation in dynamic industrial environments.

[0081] Deeply coupling load sensing, elastic resource allocation, and self-healing mechanisms creates a closed-loop optimization link. Compared to existing technologies, the system reduces task scheduling latency, improves resource utilization, and reduces the deadlock rate to near zero without increasing hardware redundancy. Its kernel-level integrated design ensures atomic control of physical resources, supports cross-hardware platform deployment of industrial equipment, and significantly reduces production line upgrade costs. Furthermore, the self-healing mechanism-driven dynamic parameter correction and abnormal unit isolation strategy reduce the frequency of manual operation and maintenance intervention, providing a highly reliable and highly adaptable real-time data processing solution for industrial control scenarios.

[0082] It should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of additional identical elements in the process, method, article, or device comprising the element.

[0083] While embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions, and variations may be made to these embodiments without departing from the principles and spirit of the invention, and that the scope of the invention is defined by the appended claims and their equivalents.

Claims

1. Industrial control data processing system based on embedded real-time operating system, characterized by: include: Dynamic weight assessment module, resource elastic allocation module and dual self-healing verification module; The dynamic weight evaluation module is used to generate a dynamic weight value based on the task type, data security level, deadline margin and historical execution exception rate; The resource elastic allocation module includes a virtual resource elastic pool and a load prediction engine. The virtual resource elastic pool abstracts CPU computing power, memory blocks, and I / O channels into dynamically divisible virtual units. The load prediction engine predicts future load peaks based on sliding window time series analysis and a lightweight LSTM network and generates resource pre-allocation instructions. The dual self-healing verification module includes a pre-execution sandbox unit and a runtime error correction unit. The pre-execution sandbox unit detects potential deadlock loops in the task resource occupation path through a directed acyclic graph traversal algorithm, and the runtime error correction unit triggers a reverse tracing mechanism when a task fails to complete twice in a row. The output end of the dynamic weight evaluation module is communicatively connected to the input end of the resource elastic allocation module, and the output end of the resource elastic allocation module is communicatively connected to the input end of the dual self-healing verification module to form a closed-loop scheduling link.

2. The industrial control data processing system based on an embedded real-time operating system according to claim 1, characterized in that: In the dynamic weight evaluation module: Task types include periodic tasks and non-periodic tasks. Data security levels are divided into security instructions, regular instructions, and low-priority instructions according to industrial control security standards. The deadline margin is calculated by the ratio of the remaining execution time window to the total duration of the task. The historical execution exception rate is based on the number of timeouts or failures in the task's historical execution records. The dynamic weight value is generated by fusing four-dimensional parameters through a nonlinear normalization algorithm and is refreshed every millisecond.

3. The industrial control data processing system based on an embedded real-time operating system according to claim 1, characterized in that: In the resource elastic allocation module: 10% of the total resources in the virtual resource elastic pool are reserved as elastic redundancy units, which are dedicated to responding to sudden tasks; High-weight tasks are preferentially bound to high-computing-power virtual units, while low-weight tasks share the remaining virtual units using a time-slice rotation mechanism. The load prediction engine has a prediction time window of 5ms and dynamically adjusts the prediction model parameters based on historical load data.

4. The industrial control data processing system based on an embedded real-time operating system according to claim 1, characterized in that: The pre-execution sandbox unit performs the following operations: Before tasks are loaded into the scheduling queue, simulate the task resource occupation path and the dependencies between tasks; If a deadlock loop is detected, the dynamic weight values ​​of the conflicting tasks are automatically downgraded and the resource allocation path is reconstructed; The reconstructed resource allocation path avoids the virtual units occupied by conflicting tasks.

5. The industrial control data processing system based on an embedded real-time operating system according to claim 1, characterized in that: The runtime error correction unit performs the following operations: When a task is not completed within the time window specified by the dynamic weight value twice in a row, the reverse tracing mechanism is triggered; Analyze the virtual unit map and scheduling logs occupied during task execution, dynamically modify weight function parameters or isolate abnormal virtual units; The corrected weight function parameters are updated to the dynamic weight evaluation module in real time.

6. The industrial control data processing system based on an embedded real-time operating system according to claim 1, characterized in that: In the dual self-healing verification module: The output of the pre-execution sandbox unit is connected to the input of the runtime error correction unit to form a priori-posteriori collaborative mechanism; The a priori-posteriori collaborative mechanism associates pre-verification results with runtime exception data to dynamically optimize the model parameters of the load prediction engine.

7. The industrial control data processing system based on an embedded real-time operating system according to claim 3, characterized in that: In the time slice rotation mechanism: Low-weight tasks are sorted by dynamic weight values ​​and allocated time slices of the same virtual unit in sequence; The length of each time slice is dynamically adjusted according to the current system load status, and the adjustment range is 10μs to 200μs.

8. The industrial control data processing system based on an embedded real-time operating system according to claim 1, characterized in that: The dynamic weight evaluation module, resource elastic allocation module and dual self-healing verification module are integrated into the kernel layer of the embedded real-time operating system and directly call the physical resources of the CPU, memory and I / O through the hardware abstraction layer.

9. An industrial control data processing method based on an embedded real-time operating system, characterized in that: The system according to any one of claims 1 to 8 is used to implement The following steps are involved: S1: collects task attributes and real-time load status; S2: Generate dynamic weight values ​​according to four-dimensional parameters and refresh; S3: Pre-allocate virtual units to task queues based on load prediction results; S4: Reconstruct the resource path of the conflicting task through pre-execution sandbox verification; S5: Schedule task execution and trigger the runtime reverse error correction mechanism; S6: Update the weight function parameters and resource allocation strategy based on the error correction results.

10. The industrial control data processing method based on an embedded real-time operating system according to claim 9, characterized in that: In the runtime reverse error correction mechanism: If a task is not completed twice in a row, the virtual unit it occupies will be isolated and marked as an abnormal unit; The abnormal unit is prohibited from being allocated in the subsequent three scheduling cycles until the parameter correction and function verification are completed.

Images