Industrial real-time task hierarchical isolation scheduling method and system based on LXC container
By adopting an industrial real-time task hierarchical isolation scheduling method based on LXC containers, precise task isolation and dynamic resource adjustment are achieved, solving the problems of resource competition and static configuration in existing technologies, and improving the efficiency and reliability of industrial real-time task scheduling.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- DAO LI ZHIYUAN TECH (QINGDAO) CO LTD
- Filing Date
- 2025-12-31
- Publication Date
- 2026-05-05
AI Technical Summary
Existing container technology lacks targeted time isolation design in industrial real-time task scheduling. High-priority tasks are easily interfered with by low-priority tasks. Static resource allocation configuration leads to large fluctuations in utilization. When multiple levels of tasks share resources, priority coordination is imperfect, affecting system stability.
The industrial real-time task hierarchical isolation scheduling method based on LXC containers achieves precise task isolation and dynamic resource adjustment through NUMA-aware resource partitioning, customized LXC runtime environment, dynamic priority algorithm and CREM module, and ensures system stability by combining feedback optimization mechanism.
It significantly improves the efficiency and reliability of industrial real-time task scheduling, ensures the real-time response capability of high-priority tasks, enhances the isolation and security between tasks, improves resource utilization, and enhances the adaptability and stability of the system.
Smart Images
Figure CN121979614A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of industrial real-time operating system technology, specifically to an industrial real-time task hierarchical isolation scheduling method and system based on LXC containers. Background Technology
[0002] Real-time task scheduling is a core support for ensuring the stable operation of industrial production systems. Especially in mixed-critical task scenarios that simultaneously handle hard real-time (response latency ≤100μs) and soft real-time (response latency ≥1ms) requirements, the determinism of task execution, the effectiveness of resource isolation, and the flexibility of dynamic adjustments directly affect the continuity and reliability of the production process. With the development of lightweight virtualization technology, containers, due to their low resource overhead and high deployment efficiency, have gradually become the preferred carrier for deploying industrial real-time tasks. However, in practical applications, how to achieve precise isolation of tasks of different critical levels, dynamic resource adaptation, and efficient priority management in a container environment to meet the stringent requirements of real-time performance and stability in industrial scenarios remains a key technical challenge that urgently needs to be overcome.
[0003] Existing container technologies have several shortcomings in industrial real-time task scheduling practices: traditional container solutions lack targeted time isolation design, making it difficult to effectively avoid resource contention between tasks of different priorities. This can lead to high-priority tasks being interfered with by low-priority tasks, affecting real-time response performance; resource allocation often adopts a static configuration mode, failing to dynamically adjust according to task load fluctuations, resulting in significant fluctuations in hardware resource utilization and hindering the full release of hardware potential; when multiple levels of tasks share resources, the priority coordination mechanism is not perfect, easily leading to task deadline mismatches, which adversely affects the overall system stability. These issues, to some extent, limit the deep application of lightweight containers in industrial real-time task scheduling scenarios. To address these issues, we propose an industrial real-time task hierarchical isolation scheduling method and system based on LXC containers. Summary of the Invention
[0004] To address the aforementioned technical issues, this paper provides a hierarchical isolation scheduling method and system for industrial real-time tasks based on LXC containers. This technical solution resolves the shortcomings in industrial real-time task scheduling mentioned above: lack of targeted time isolation design, high-priority tasks are easily interfered with by resource contention of low-priority tasks; resource allocation is mostly statically configured, making it difficult to adjust with load fluctuations, resulting in large fluctuations in utilization; and imperfect priority coordination when multiple levels of tasks share resources, which easily leads to deadline matching deviations and limits its in-depth application in this scenario.
[0005] To achieve the above objectives, the technical solution adopted by the present invention is as follows:
[0006] The industrial real-time task hierarchical isolation scheduling method based on LXC containers includes the following steps:
[0007] S1. Perform NUMA-aware resource partitioning on physical hardware, isolate CPU cores according to task criticality, reserve memory bandwidth channels, and implement pass-through control for real-time devices.
[0008] S2. Create a customized LXC runtime environment, build a real-time namespace, establish a secure isolation domain through mandatory access control, and optimize container context switching overhead.
[0009] S3. Load the criticality level, deadline, and resource requirements from the task metadata, and initialize the basic weights of the dynamic priority algorithm.
[0010] S4. Real-time collection of task execution indicators, calculation of urgency factor dynamic adjustment weight, implementation of weight reduction penalty for over-limit tasks, and dynamic allocation of spare computing resources to high-priority tasks through the CREM module.
[0011] S5. The monitoring unit of the CREM module periodically collects the system status, the decision unit of the CREM module matches the preset strategy template to generate a resource allocation scheme, and the execution unit of the CREM module updates the container resource quota with atomic operations.
[0012] S6. Feedback the task execution status to the scheduling layer in real time, triggering abnormal migration or policy reconfiguration, and continuously optimizing the scheduling strategy based on historical data.
[0013] Preferably, in step S1, the NUMA-aware resource allocation for the physical hardware specifically includes:
[0014] Identify the non-uniform memory access architecture characteristics of physical servers, divide physical CPU computing cores into different resource partitions according to the criticality level of tasks, and schedule tasks of the same criticality level to run on the cores within the same NUMA node.
[0015] Reserve dedicated memory bandwidth access channels for time-sensitive missions, and restrict non-critical missions from competing for memory bandwidth through memory controller configuration;
[0016] For real-time input / output devices that require deterministic access, configure PCIe device pass-through mode, allowing mission-critical containers to exclusively access the physical device.
[0017] Preferably, in step S2, creating a customized LXC runtime environment specifically includes:
[0018] A real-time namespace is built on top of LXC container technology. The time scheduling parameters in this namespace are independent of the host machine and other container namespaces, and it is used to deploy time-sensitive tasks.
[0019] Establish a secure isolation domain based on the SMACK mandatory access control mechanism to restrict unauthorized process communication and resource access between containers;
[0020] Optimize the container runtime environment, reduce container context switching overhead, and perform low-latency optimization for the switching path of real-time task containers, including reducing kernel lock contention and optimizing process state saving and recovery mechanisms.
[0021] Preferably, the specific operation of the dynamic priority algorithm in steps S3 and S4 includes:
[0022] When a task is started, its basic scheduling weight is initialized based on the predefined critical level, deadline requirements, and resource requirements parameters in the task metadata.
[0023] During task execution, the actual execution time, remaining deadline, and resource utilization rate of the task are collected in real time, the task urgency factor is calculated, and the current scheduling weight of the task is dynamically adjusted.
[0024] For tasks that exceed the execution limits, a penalty of reducing their scheduling weight will be imposed.
[0025] When the system detects that a high-priority task may not be able to meet the deadline due to insufficient resources, the CREM module makes a decision and executes the immediate allocation of spare resources.
[0026] Preferably, in step S5, the specific operation process of the CREM module includes:
[0027] The monitoring unit periodically collects system status data in the range of 1 to 100 microseconds at a configurable period, including CPU utilization, memory bandwidth usage, task queue length, and deadline fulfillment status of each container task.
[0028] The decision-making unit receives monitoring data, matches and evaluates it against the built-in preset scheduling strategy template, and selects or combines it to generate a resource allocation scheme based on the current system load characteristics and task criticality requirements.
[0029] The execution unit receives resource allocation instructions from the decision-making unit and updates the resource quota configuration of the target container in an atomic operation manner, including CPU time slice limits, CPU core binding relationships, and memory bandwidth limits.
[0030] Preferably, in step S6, the feedback optimization mechanism specifically includes:
[0031] The key status information of task execution, including task completion status, actual execution time, whether the deadline was missed, resource usage, and abnormal events, is fed back to the dynamic priority scheduler and CREM module of the scheduling layer in real time.
[0032] When a task is detected to be continuously exceeding limits, severely conflicting resources, or in an abnormal state of hardware failure, the abnormal migration or policy reconfiguration process of the task between different containers within the physical host is triggered. The CREM module selects the migration target or generates a new resource allocation scheme based on the type of abnormality.
[0033] The decision-making unit of the CREM module combines historically collected system status data and scheduling result data to continuously evaluate and optimize the scheduling strategy template.
[0034] An industrial real-time task hierarchical isolation scheduling system based on LXC containers is used to implement the industrial real-time task hierarchical isolation scheduling method based on LXC containers, including: a hardware abstraction layer, a virtualization layer and a scheduling layer.
[0035] The hardware abstraction layer is used to manage and allocate physical hardware resources and provide an isolated hardware execution environment for the upper layer, including: CPU core binding module, memory bandwidth control unit and PCIe device pass-through component;
[0036] The virtualization layer, based on the environment provided by the hardware abstraction layer, builds a runtime environment on a lightweight LXC container to carry task instances of different critical levels, including: real-time namespace, security isolation domain and lightweight context manager;
[0037] The scheduling layer, based on the task status of the virtualization layer, dynamically coordinates task priorities and decides resource allocation strategies according to the task criticality level and the real-time system status, including: a dynamic priority scheduler and a CREM module;
[0038] The hardware abstraction layer, virtualization layer, and scheduling layer are connected in sequence and work together.
[0039] Preferably, the hardware abstraction layer specifically includes:
[0040] The CPU core binding module performs resource partitioning operations that are aware of the non-unified memory access architecture, dividing and binding physical CPU cores according to the task criticality level;
[0041] The memory bandwidth control unit configures and manages the allocation and reservation of memory bandwidth, and sets the memory bandwidth access limit or guarantees the bandwidth for mission-critical containers.
[0042] The PCIe device passthrough component manages access control for high-speed peripheral devices, assigning specific real-time input / output devices to designated mission-critical containers in passthrough mode.
[0043] Preferably, the virtualization layer specifically includes:
[0044] The real-time namespace, built on a customized LXC runtime environment, provides an independent time scheduling environment for time-sensitive tasks;
[0045] The security isolation domain is implemented based on the SMACK mandatory access control mechanism, which enforces fine-grained inter-process communication and resource access control policies at the container level.
[0046] The lightweight context manager optimizes the task switching process in a container environment by simplifying the kernel switching path and optimizing the process state saving and recovery mechanism.
[0047] Preferably, the CREM module in the scheduling layer specifically includes:
[0048] The real-time monitoring unit collects system runtime status data, including container-level resource usage metrics and task execution status, at configurable intervals of 1 to 100 microseconds.
[0049] The strategy decision-making unit stores and manages preset scheduling strategy templates, and matches or generates resource allocation decisions based on the data input by the monitoring unit;
[0050] The resource allocation execution unit transforms the output of the decision-making unit into specific container resource control group configuration parameters, and applies the configuration update to the container runtime environment in an atomic manner.
[0051] Compared with the prior art, the beneficial effects of the present invention are as follows:
[0052] The proposed industrial real-time task hierarchical isolation scheduling method and system significantly improves the efficiency and reliability of industrial real-time task scheduling through innovative resource partitioning and management mechanisms. Utilizing NUMA-aware technology, it effectively isolates task resources at different critical levels, reduces resource contention, and ensures the real-time response capability of high-priority tasks. The customized LXC runtime environment, combined with real-time namespaces and secure isolation domains, enhances the isolation and security between tasks. The introduction of dynamic priority algorithms and CREM modules allows resource allocation to be flexibly adjusted according to the actual execution status of tasks, improving resource utilization. The feedback optimization mechanism ensures continuous optimization of the scheduling strategy, enhancing the system's adaptability and stability. Attached Figure Description
[0053] Figure 1 This is a flowchart of the method of the present invention;
[0054] Figure 2 This is a system framework diagram of the present invention. Detailed Implementation
[0055] The following description is intended to disclose the invention and enable those skilled in the art to implement it. The preferred embodiments described below are merely examples, and other obvious variations will occur to those skilled in the art.
[0056] Reference Figure 1 As shown, the core of the LXC container-based hierarchical isolation scheduling method for industrial real-time tasks lies in ensuring the deterministic execution of critical real-time tasks through fine-grained resource isolation and dynamic scheduling strategies. This method first performs NUMA-aware resource partitioning on the physical hardware. This requires identifying the non-uniform memory access architecture characteristics of the server and understanding the impact of differences in access latency at different memory locations on real-time performance. Based on the predefined criticality level of the task, the physical CPU computing cores are strictly divided into different resource partitions, ensuring that tasks of the same criticality level are scheduled to run on cores within the same NUMA node, minimizing unpredictable latency caused by cross-node memory access. For time-sensitive critical tasks, dedicated memory bandwidth access channels need to be reserved. This is typically achieved by configuring the memory controller, such as setting bandwidth quotas or priorities for specific channels, thereby effectively limiting contention for memory bandwidth by non-critical tasks and preventing critical tasks from missing deadlines due to insufficient memory bandwidth. For real-time input / output devices requiring deterministic low-latency access, such as interface cards for specific sensors or actuators, configuring pass-through mode for PCIe devices is necessary, enabling critical task containers to bypass the virtualization layer and directly and exclusively access the underlying physical devices, eliminating the uncertainty introduced by I / O virtualization.
[0057] In terms of building the runtime environment, this method creates a customized LXC runtime environment. Building a real-time namespace is a crucial step on top of standard LXC container technology. This namespace has time scheduling parameters independent of the host machine and other container namespaces, such as independent real-time scheduling policies and priority configurations, specifically designed for deploying time-sensitive tasks, ensuring their scheduling is not interfered with by other non-real-time loads. To enhance security and isolation, a secure isolation domain is established based on the SMACK mandatory access control mechanism. SMACK provides stricter mandatory access control than traditional DAC, enabling fine-grained restriction of unauthorized process communication and unauthorized resource access paths between containers, preventing malicious or faulty containers from affecting critical tasks. Simultaneously, given the stringent requirements of real-time tasks, the container runtime environment must be optimized, particularly reducing container context switching overhead. This involves low-latency optimization of the switching paths for real-time task containers, such as analyzing and reducing lock contention points on critical kernel paths, optimizing process state saving and restoration mechanisms, and compressing the time required for task switching as much as possible to meet microsecond-level real-time constraints.
[0058] Task scheduling weight management is a dynamic process. During the task startup initialization phase (step S3), the scheduler assigns a basic scheduling weight to the task based on predefined criticality levels, deadline requirements, and resource requirements parameters in the task metadata. Tasks with higher criticality levels and tighter deadlines have correspondingly higher basic weights, giving them an advantage in initial scheduling. After entering the task execution phase (step S4), the system collects key indicators in real time, such as the task's actual execution time, remaining time until the deadline, CPU utilization, and memory bandwidth usage. Based on these indicators, a dynamic urgency factor is calculated. This factor typically considers factors such as the ratio of remaining execution time to remaining deadline and the degree to which resource requirements are met, and is used to dynamically adjust the task's current scheduling weight. When a task's actual execution time exceeds the estimate or its resource usage continues to exceed the limit, it is detected as exceeding execution limits. At this time, the system will implement a weight reduction penalty for the task, lowering its priority in acquiring CPU resources to prevent it from crowding out other tasks' resources. More importantly, when the system detects that a high-priority task may face the risk of not meeting its deadline due to insufficient current resource allocation, it will trigger the intervention of the CREM module. The CREM module can make decisions and execute the immediate allocation of spare computing resources, such as temporarily increasing CPU quotas, binding to reserved cores, or increasing memory bandwidth limits, to provide emergency resource guarantees for high-priority tasks.
[0059] The CREM module, as the core of dynamic resource management, has its operation process defined in detail in step S5. The monitoring unit continuously collects key system status data at a highly configurable period (typically between 1 and 100 microseconds, with the specific period set according to the system's real-time requirements; the more stringent the requirements, the shorter the period). This data includes CPU utilization of each container task, actual memory bandwidth usage, task ready queue length, and whether task deadlines have been met, providing real-time basis for decision-making. The decision-making unit receives the data stream from the monitoring unit and matches and evaluates it against a built-in library of preset scheduling strategy templates. These strategy templates predefine resource adjustment rules for different load characteristics (such as CPU-intensive and memory-bandwidth-sensitive) and different combinations of task criticality. The decision-making unit analyzes the current system load characteristics and the critical requirements of the tasks, selecting the most suitable existing strategy template, or generating new resource allocation schemes more suitable for the current scenario based on complex rule combinations. The execution unit is responsible for transforming the abstract resource allocation instructions issued by the decision-making unit into specific, operable control commands. After receiving the instructions, it directly updates the resource quota configuration of the target container in an atomic operation manner. These update operations include, but are not limited to, adjusting CPU time slice limits, modifying CPU core binding relationships (migrating tasks to specific cores), setting or modifying memory bandwidth limits, etc., to ensure the timeliness and consistency of resource adjustments and avoid problems caused by intermediate states.
[0060] The entire scheduling process forms a closed loop, with step S6 defining the feedback optimization mechanism. Key status information during task execution, including final task completion status, actual execution time, whether deadlines were missed, resource usage, and any abnormal events, is fed back in real-time to the dynamic priority scheduler and CREM module at the scheduling layer. This feedback information forms the basis for the system's perception of environmental changes and its own state. When the system detects abnormal states such as task execution exceeding limits, severe resource allocation conflicts (e.g., multiple critical tasks vying for the same core), or hardware failures, it immediately triggers an exception handling process. This typically includes abnormal migration operations between different containers within the physical host or emergency reconfiguration of existing scheduling strategies. The CREM module's decision unit intelligently selects the target container location for migration or generates a completely new resource allocation scheme to address the crisis, based on the detected exception type and the current system resource status. In addition to real-time response, the CREM module's decision unit also possesses learning optimization capabilities. It continuously evaluates and fine-tunes the preset scheduling strategy template by combining historically collected system status data (e.g., load fluctuation patterns) and scheduling result data (e.g., task overdue rate, resource utilization). For example, by analyzing the completion status of high-priority tasks under a specific strategy, adjusting the threshold or coefficients in the weight calculation formula for resource allocation, the scheduling strategy can adapt to changes in the long-term operating environment and continuously improve the overall scheduling performance and real-time guarantee capability of the system.
[0061] refer to Figure 2 As shown, the industrial real-time task hierarchical isolation scheduling system implemented based on the above method has a clearly defined architecture consisting of three core layers: a hardware abstraction layer, a virtualization layer, and a scheduling layer, each working collaboratively. The hardware abstraction layer is the foundation of the system, directly managing and allocating physical hardware resources to build a strongly isolated hardware execution environment for the upper layers. This layer contains three key components: a CPU core binding module that performs NUMA-aware resource partitioning operations, interacting directly with the hardware and operating system kernel, responsible for physically partitioning and binding physical CPU cores according to the predefined criticality levels of tasks, ensuring strict isolation of core resources; a memory bandwidth control unit responsible for configuring and managing memory bandwidth allocation and reservation strategies, which may set upper limits for memory bandwidth access for critical task containers through the operating system's memory controller interface or specific hardware registers, or more importantly, provide a minimum guaranteed bandwidth to resist interference from other tasks; and a PCIe device passthrough component that manages the access control logic for high-speed peripheral devices. Utilizing hardware virtualization support, it allocates specific real-time input / output devices requiring deterministic access to designated critical task containers in passthrough mode for exclusive use, bypassing any software layers that may introduce latency.
[0062] The virtualization layer is built upon the isolated resources provided by the hardware abstraction layer. Its core is the use of lightweight LXC container technology to construct a task runtime environment that hosts task instances of varying criticality levels. This layer comprises three main parts: a real-time namespace built upon a deeply customized LXC runtime environment. Customization involves modifying container startup and runtime logic to ensure a completely independent, configurable real-time scheduling environment for time-sensitive tasks, with its scheduling behavior isolated from the host machine and other non-real-time containers. The implementation of the security isolation domain relies on the SMACK mandatory access control mechanism. SMACK is integrated into the container management framework, enforcing fine-grained inter-process communication control and resource access control policies at the container level. Any access across the isolation domain must undergo strict policy checks, effectively curbing fault propagation and security threats. The lightweight context manager focuses on optimizing the task switching process within the container environment. By analyzing kernel task switching paths, streamlining unnecessary operations, and optimizing the code efficiency of process state saving and restoration, it significantly reduces context switching latency between real-time task containers or between containers and the host machine.
[0063] The scheduling layer, located at the top, dynamically coordinates task priorities and makes resource allocation strategy decisions based on the real-time status information of tasks running in the virtualization layer, according to the task's criticality level and the overall real-time load of the system. This layer consists of two core components: the dynamic priority scheduler, which manages the task scheduling queue and allocates CPU time. It calculates and adjusts the task scheduling priority in real time based on the task's basic criticality level and dynamic weights calculated at runtime (including urgency factors and possible demotion penalties), determining which task gets CPU execution rights and when. The CREM module is crucial for the system's elastic resource management, containing three cooperating sub-units. The real-time monitoring unit acts as the system's "eyes," actively collecting system runtime status data at extremely short, configurable intervals (1-100 microseconds), including container-level CPU utilization, memory bandwidth usage, task queue status, and deadline fulfillment status. The strategy decision-making unit is the system's "brain," storing and managing a series of preset scheduling strategy templates. This unit receives real-time data streams from the monitoring unit, matches and evaluates them against built-in policy templates, and selects the most suitable existing policy or dynamically combines them to generate a new resource allocation decision scheme based on a comprehensive analysis of the current system load characteristics and task criticality requirements. The resource allocation execution unit acts as the system's "hand," transforming the abstract resource allocation instructions output by the decision unit into specific resource control group configuration parameters that can be applied to the container runtime. It then uses atomic operations to securely and instantly apply these configuration updates to the target container's runtime environment, completing the actual adjustment of resource quotas. These three layers are connected through clear interfaces: the hardware abstraction layer provides resource guarantees for the virtualization layer, the virtualization layer provides task running status and resource control interfaces for the scheduling layer, and the scheduling layer's decisions, in turn, act on the hardware abstraction layer through the virtualization layer to allocate resources, forming a complete closed-loop control system.
[0064] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the claimed invention. The scope of protection claimed by the appended claims and their equivalents is defined.
Claims
1. A hierarchical isolation scheduling method for industrial real-time tasks based on LXC containers, characterized in that, Includes the following steps: S1. Perform NUMA-aware resource partitioning on physical hardware, isolate CPU cores according to task criticality, reserve memory bandwidth channels, and implement pass-through control for real-time devices. S2. Create a customized LXC runtime environment, build a real-time namespace, establish a secure isolation domain through mandatory access control, and optimize container context switching overhead. S3. Load the criticality level, deadline, and resource requirements from the task metadata, and initialize the basic weights of the dynamic priority algorithm. S4. Real-time collection of task execution indicators, calculation of urgency factor dynamic adjustment weight, implementation of weight reduction penalty for over-limit tasks, and dynamic allocation of spare computing resources to high-priority tasks through the CREM module. S5. The monitoring unit of the CREM module periodically collects the system status, the decision unit of the CREM module matches the preset strategy template to generate a resource allocation scheme, and the execution unit of the CREM module updates the container resource quota with atomic operations. S6. Feedback the task execution status to the scheduling layer in real time, triggering abnormal migration or policy reconfiguration, and continuously optimizing the scheduling strategy based on historical data.
2. The industrial real-time task hierarchical isolation scheduling method based on LXC containers according to claim 1, characterized in that, In step S1, the NUMA-aware resource allocation for physical hardware specifically includes: Identify the non-uniform memory access architecture characteristics of physical servers, divide physical CPU computing cores into different resource partitions according to the criticality level of tasks, and schedule tasks of the same criticality level to run on the cores within the same NUMA node. Reserve dedicated memory bandwidth access channels for time-sensitive missions, and restrict non-critical missions from competing for memory bandwidth through memory controller configuration; For real-time input / output devices that require deterministic access, configure PCIe device pass-through mode, allowing mission-critical containers to exclusively access the physical device.
3. The industrial real-time task hierarchical isolation scheduling method based on LXC containers according to claim 1, characterized in that, In step S2, creating a customized LXC runtime environment specifically includes: A real-time namespace is built on top of LXC container technology. The time scheduling parameters in this namespace are independent of the host machine and other container namespaces, and it is used to deploy time-sensitive tasks. Establish a secure isolation domain based on the SMACK mandatory access control mechanism to restrict unauthorized process communication and resource access between containers; Optimize the container runtime environment, reduce container context switching overhead, and perform low-latency optimization for the switching path of real-time task containers, including reducing kernel lock contention and optimizing process state saving and recovery mechanisms.
4. The industrial real-time task hierarchical isolation scheduling method based on LXC containers according to claim 1, characterized in that, The specific operation of the dynamic priority algorithm in steps S3 and S4 includes: When a task is started, its basic scheduling weight is initialized based on the predefined critical level, deadline requirements, and resource requirements parameters in the task metadata. During task execution, the actual execution time, remaining deadline, and resource utilization rate of the task are collected in real time, the task urgency factor is calculated, and the current scheduling weight of the task is dynamically adjusted. For tasks that exceed the execution limits, a penalty of reducing their scheduling weight will be imposed. When the system detects that a high-priority task may not be able to meet the deadline due to insufficient resources, the CREM module makes a decision and executes the immediate allocation of spare resources.
5. The industrial real-time task hierarchical isolation scheduling method based on LXC containers according to claim 1, characterized in that, In step S5, the specific operation process of the CREM module includes: The monitoring unit periodically collects system status data in the range of 1 to 100 microseconds at a configurable period, including CPU utilization, memory bandwidth usage, task queue length, and deadline fulfillment status of each container task. The decision-making unit receives monitoring data, matches and evaluates it against the built-in preset scheduling strategy template, and selects or combines it to generate a resource allocation scheme based on the current system load characteristics and task criticality requirements. The execution unit receives resource allocation instructions from the decision-making unit and updates the resource quota configuration of the target container in an atomic operation manner, including CPU time slice limits, CPU core binding relationships, and memory bandwidth limits.
6. The industrial real-time task hierarchical isolation scheduling method based on LXC containers according to claim 1, characterized in that, In step S6, the feedback optimization mechanism specifically includes: The key status information of task execution, including task completion status, actual execution time, whether the deadline was missed, resource usage, and abnormal events, is fed back to the dynamic priority scheduler and CREM module of the scheduling layer in real time. When a task is detected to be continuously exceeding limits, severely conflicting resources, or in an abnormal state of hardware failure, the abnormal migration or policy reconfiguration process of the task between different containers within the physical host is triggered. The CREM module selects the migration target or generates a new resource allocation scheme based on the type of abnormality. The decision-making unit of the CREM module combines historically collected system status data and scheduling result data to continuously evaluate and optimize the scheduling strategy template.
7. An industrial real-time task hierarchical isolation scheduling system based on LXC containers, characterized in that, The method for implementing the industrial real-time task hierarchical isolation scheduling method based on LXC containers as described in any one of claims 1-6 includes: a hardware abstraction layer, a virtualization layer, and a scheduling layer; The hardware abstraction layer is used to manage and allocate physical hardware resources and provide an isolated hardware execution environment for the upper layer, including: CPU core binding module, memory bandwidth control unit and PCIe device pass-through component; The virtualization layer, based on the environment provided by the hardware abstraction layer, builds a runtime environment on a lightweight LXC container to carry task instances of different critical levels, including: real-time namespace, security isolation domain and lightweight context manager; The scheduling layer, based on the task status of the virtualization layer, dynamically coordinates task priorities and decides resource allocation strategies according to the task criticality level and the real-time system status, including: a dynamic priority scheduler and a CREM module; The hardware abstraction layer, virtualization layer, and scheduling layer are connected in sequence and work together.
8. The industrial real-time task hierarchical isolation scheduling system based on LXC containers according to claim 7, characterized in that, The hardware abstraction layer specifically includes: The CPU core binding module performs resource partitioning operations that are aware of the non-unified memory access architecture, dividing and binding physical CPU cores according to the task criticality level; The memory bandwidth control unit configures and manages the allocation and reservation of memory bandwidth, and sets the memory bandwidth access limit or guarantees the bandwidth for mission-critical containers. The PCIe device passthrough component manages access control for high-speed peripheral devices, assigning specific real-time input / output devices to designated mission-critical containers in passthrough mode.
9. The industrial real-time task hierarchical isolation scheduling system based on LXC containers according to claim 7, characterized in that, The virtualization layer specifically includes: The real-time namespace, built on a customized LXC runtime environment, provides an independent time scheduling environment for time-sensitive tasks; The security isolation domain is implemented based on the SMACK mandatory access control mechanism, which enforces fine-grained inter-process communication and resource access control policies at the container level. The lightweight context manager optimizes the task switching process in a container environment by simplifying the kernel switching path and optimizing the process state saving and recovery mechanism.
10. The industrial real-time task hierarchical isolation scheduling system based on LXC containers according to claim 7, characterized in that, The CREM module in the scheduling layer specifically includes: The real-time monitoring unit collects system runtime status data, including container-level resource usage metrics and task execution status, at configurable intervals of 1 to 100 microseconds. The strategy decision-making unit stores and manages preset scheduling strategy templates, and matches or generates resource allocation decisions based on the data input by the monitoring unit; The resource allocation execution unit transforms the output of the decision-making unit into specific container resource control group configuration parameters, and applies the configuration update to the container runtime environment in an atomic manner.