Hybrid scheduling method based on containerized mixed-criticality system

Abstract

The present invention relates to a hybrid scheduling method based on a containerized mixed-criticality system, specifically comprising the following steps: configuring a first-level scheduling policy in two-level real-time scheduling within a scheduling blueprint, and establishing a major time frame and container time frames: setting a duration of the major time frame, and setting an execution sequence and execution durations of real-time containers within each major time frame; configuring a second-level scheduling policy in the two-level real-time scheduling; configuring the number of time slices that can be occupied by each non-real-time task upon being scheduled; creating containers and starting the containers, and a system running according to the scheduling blueprint; and when a real-time container, a real-time task, a non-real-time container or a non-real-time task is suspended or terminated, the system automatically adjusting a corresponding execution sequence and execution durations. The present invention solves the problem that existing hierarchical scheduling policies for real-time containers cannot ensure the minimum response time of each real-time task, thereby ensuring that the response of real-time tasks can be more timely, and satisfying actual requirements of different types of critical tasks.

Description

A Hybrid Scheduling Method Based on Containerized Hybrid Critical Systems Technical Field

[0001] This invention relates to the field of embedded real-time operating systems, and in particular to a hybrid scheduling method based on containerized hybrid critical systems. Background Technology

[0002] On the same hardware platform, real-time containers that run only real-time tasks and non-real-time containers that run only non-real-time tasks are integrated. They have different criticalities and time constraints. We call such a system a containerized hybrid critical system.

[0003] In containerized hybrid mission-critical systems, it is crucial to ensure both the determinism and real-time performance of real-time tasks within real-time containers, and to guarantee that non-real-time containers can respond within a finite timeframe without starvation. Therefore, the efficient scheduling of real-time and non-real-time containers becomes a critical challenge.

[0004] The paper "Container Scheduling Architecture Design for Hybrid Critical Systems," published in the journal *Computer Science*, Vol. 6, 2023, proposes a container scheduling and management mechanism for hybrid critical systems. Based on a hierarchical scheduling model, it schedules the real-time run queues of container control groups (which can be understood as process groups), ensuring the real-time performance of each real-time container while limiting the container resources allocated to non-real-time containers. It also incorporates load monitoring and balancing strategies, dynamically adjusting resources to allocate resources reasonably to non-real-time containers. This approach ensures the real-time performance of real-time containers while allowing non-real-time containers to respond within a limited timeframe, preventing them from being constantly preempted and "starved."

[0005] In the hierarchical scheduling concept mentioned in the aforementioned literature, all container control groups are associated with explicitly specified runtimes and periods, and the SCHED_DEADLINE scheduling policy limits the CPU usage of real-time tasks within a control group to a threshold that does not exceed the control group's CPU utilization (i.e., the ratio of specified runtime to period). For real-time containers, a hierarchical scheduling mechanism is employed, which is a two-level scheduling hierarchy. The first level uses the SCHED_DEADLINE scheduling policy to handle container-level scheduling, scheduling the real-time run queues of each container control group to ensure that each real-time container is scheduled for execution. The second level uses a fixed-priority scheduling policy to schedule tasks within containers. Tasks running within a control group are only scheduled if the control group's deadline entity has already been scheduled by SCHED_DEADLINE. For non-real-time containers, the system dynamically adjusts the CPU capacity allocated to each non-real-time container at runtime through a dynamic adjustment module. Simultaneously, to adapt to the variable workload of non-real-time containers, a performance monitoring module collects the CPU utilization of non-real-time containers every second, and the dynamic adjustment module uses this information to determine how to adjust CPU allocation.

[0006] While the hierarchical scheduling strategy used by real-time containers ensures that each container control group completes before the deadline, it cannot guarantee the minimum response time for every real-time task. The reason is as follows: The first level uses the SCHED_DEADLINE scheduling strategy, meaning the control group with the shortest deadline will be served first. However, from the perspective of the entire system, high-priority real-time tasks are not necessarily the shortest-deadline tasks, nor are they necessarily in the shortest-deadline control group. This can lead to issues with high-priority real-time tasks not responding promptly. Summary of the Invention

[0007] To address the issue that existing hierarchical scheduling strategies for real-time containers cannot guarantee the minimum response time for real-time tasks, a hybrid scheduling method based on containerized hybrid critical systems is proposed.

[0008] The technical solution of this invention is as follows:

[0009] A hybrid scheduling method for containerized hybrid critical systems proposes a two-level real-time scheduling algorithm based on period and time slice for critical tasks running in real-time containers, and an embedded general-purpose scheduling algorithm for non-critical tasks running in non-real-time containers. The method includes the following steps:

[0010] Step 1: Obtain the actual required scheduling blueprint, configure the first-level scheduling strategy in the second-level real-time scheduling of the scheduling blueprint in the containerized hybrid critical system, and establish the main time frame and container time frame: set the time of the main time frame, and set the execution order and execution time of each real-time container in each main time frame;

[0011] Step 2: Configure the second-level scheduling strategy in the second-level real-time scheduling of the scheduling blueprint: Based on the different criticalities of each task in each real-time container, set the scheduling order and execution time of each real-time task in the corresponding time frame of the container;

[0012] Step 3: Configure the number of time slices that each non-real-time task can occupy after being scheduled in the scheduling blueprint;

[0013] Step 4: Create and start the container; the system runs according to the scheduling blueprint.

[0014] Step 5: During system operation, if a real-time container is paused or exited, the system will automatically adjust the execution order and execution time of each real-time container within each main timeframe.

[0015] Step 6: During system operation, if a real-time task is paused or exited, the system will automatically adjust the scheduling order and execution time of other real-time tasks in the container where the real-time task is located.

[0016] Step 7: During system operation, if any non-real-time containers or non-real-time tasks are paused or exited, the system will automatically adjust the scheduling and execution sequence of the non-real-time tasks.

[0017] Furthermore, the scheduling based on the main timeframe adopts a periodic fixed-time-slice scheduling strategy: scheduling is performed in a fixed, periodic manner, based on a round-robin mechanism. By configuring the period of the scheduled container and the duration within a period, and simultaneously configuring window scheduling within the main timeframe, the scheduling order is statically set. To activate the round-robin, a main timeframe is maintained at a fixed period, and timed, repetitive execution is achieved through this framework. The main timeframe allocates a container window, i.e., a container timeframe, to each container, and determines the offset of the container window within the main timeframe and the predetermined execution time. Each container can only execute at the specified time. During the time window configuration process, the execution sequence of the containers needs to be standardized.

[0018] Furthermore, the secondary real-time scheduling algorithm is an extension of the ARINC real-time scheduling algorithm, specifically designed for the multi-tasking characteristics of real-time containers, within the main timeframe. Specifically, within the single main timeframe of the current real-time scheduling algorithm, time slices are first allocated to individual containers rather than to the task threads within them, thus forming a container timeframe for each real-time container. Each real-time container, running within its own container timeframe, further performs secondary real-time scheduling control on each task. This level of scheduling allocates time slices according to the pre-configured task timeframes for each task.

[0019] Furthermore, the hybrid scheduling strategy, based on the main timeframe and container timeframe design established by the first level of the two-level real-time scheduling algorithm, completely isolates real-time container scheduling from non-real-time container scheduling in terms of time slices, ensuring preemptive scheduling of critical tasks for non-critical tasks. Specifically, within the main timeframe of the two-level real-time scheduling algorithm, scheduling is divided into two phases: a real-time processing environment scheduling phase and a non-real-time processing environment scheduling phase. In the real-time processing environment scheduling phase, the two-level real-time scheduling algorithm is used, where each real-time container obtains a fixed number of time slices within a main timeframe and allocates them to the critical tasks within the container. In the non-real-time processing environment scheduling phase, a priority-based non-preemptive scheduling algorithm is used, that is, the task in the container with the highest priority in the non-real-time processing environment is selected for scheduling and execution. The number of time slices that each ordinary task can occupy after being scheduled in this phase can be configured. To ensure the determinism and stability of the main timeframe, if the remaining time slices of a single main timeframe are exhausted, the non-real-time scheduling phase ends immediately, and the general scheduling strategy continues only after the non-real-time processing environment scheduling phase of the next main timeframe begins.

[0020] Furthermore, when the remaining time slice of a single processor core is insufficient to meet the needs of the next real-time container to run, it is bundled and run on a new processor core. This scheduling algorithm supports multi-core scenarios and unifies the length and allocation of time slices on each physical core running real-time scheduling.

[0021] Furthermore, this method binds a processor core to each real-time container by default.

[0022] Furthermore, in step 2, the criticality of each task includes its priority, resource requirements, and execution time.

[0023] The beneficial effects of this invention are as follows:

[0024] The proposed two-level real-time scheduling algorithm for real-time containers, established in the first level, completely isolates real-time container scheduling from non-real-time container scheduling at the time slice level. This ensures preemptive scheduling of non-critical tasks by critical tasks. Within each main time frame, non-real-time task scheduling can only begin after all real-time tasks have executed their corresponding number of time slices. Furthermore, when configuring the execution order and execution time of each real-time container within the first-level main time frame, all real-time tasks within all real-time containers can be comprehensively considered. Based on factors such as their criticality, priority, resource requirements, and execution time, a reasonable container execution sequence and a reasonable task execution sequence within each container can be set, ensuring more timely responses from real-time tasks. Parameters such as the main time frame, container time frame, and the execution order and execution time of each task can be pre-configured in the scheduling blueprint and dynamically adjusted during system operation according to actual conditions.

[0025] Because different mission-critical tasks may have different real-time scheduling requirements, this project's approach provides more flexible options for container scheduling within the first-level main timeframe and task scheduling within the second-level container timeframe. Within the first-level main timeframe, the scheduling blueprint can only set the required time slice percentage for each real-time container, without configuring the execution order of the real-time containers. With this configuration, a real-time container may be scheduled multiple times within a single main timeframe, but the total execution time it receives is strictly configured according to the administrator's allocation. Within the second-level container timeframe, the administrator can configure different scheduling algorithms for each real-time container using the scheduling blueprint, thereby meeting the actual needs of various mission-critical tasks. Attached Figure Description

[0026] Figure 1 is a diagram of the hybrid scheduling strategy for critical and non-critical applications of the present invention.

[0027] Figure 2 shows the two stages of the hybrid scheduling algorithm of the present invention;

[0028] Figure 3 is a time slice allocation diagram for the secondary real-time scheduling of the present invention. Detailed Implementation

[0029] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments. These embodiments are based on the technical solution of the present invention and provide detailed implementation methods and specific operating procedures. However, the scope of protection of the present invention is not limited to the following embodiments.

[0030] In containerized hybrid critical systems, to rationally allocate CPUs between real-time and non-real-time containers, ensuring both the determinism and real-time performance of real-time tasks in real-time containers and the ability of non-real-time containers to respond within a finite time without starvation, while minimizing task response latency, especially the response latency of real-time tasks, this invention proposes a hybrid real-time scheduling method. As shown in Figure 1, critical tasks running in real-time containers employ a two-level real-time scheduling algorithm based on period and time slices, while non-critical tasks running in non-real-time containers utilize an embedded general-purpose scheduling algorithm.

[0031] The scheduling based on the major frame employs a periodic fixed-time-slice scheduling strategy: scheduling is performed in a fixed, periodic manner, using a round-robin mechanism as the basis. The scheduling order is statically set by configuring the period of the scheduled container and the duration within a period, along with window scheduling within the major frame. To activate the round-robin, a major frame is maintained at a fixed period, enabling timed and repetitive execution. The major frame allocates a container window (also called a container timeframe) to each container, determining its offset within the major frame and its scheduled execution time. Each container can only execute within its designated time and cannot cross boundaries to avoid affecting the execution of other containers. During the time window configuration process, the execution sequence of containers needs to be standardized.

[0032] The two-level real-time scheduling algorithm in this scheme is an extension of the ARINC real-time scheduling algorithm, specifically designed for the multi-tasking characteristics of real-time containers, within the main timeframe. Specifically, under the single main timeframe of the current real-time scheduling algorithm, time slices are first allocated to individual containers rather than the task threads within them, thus forming a container timeframe for each real-time container. Each real-time container, running within its own container timeframe, further performs a second level of real-time scheduling control over its tasks. This level of scheduling allocates time slices according to the pre-configured taskframes for each task.

[0033] The hybrid scheduling strategy, based on the main timeframe and container timeframe established by the first stage of the two-level real-time scheduling algorithm, completely isolates real-time container scheduling from non-real-time container scheduling in terms of time slices, ensuring preemptive scheduling of non-critical tasks for critical tasks. Specifically, within the main timeframe of the two-level real-time scheduling algorithm, scheduling is divided into two phases: a real-time processing environment scheduling phase and a non-real-time processing environment scheduling phase, as shown in Figure 2. In the real-time processing environment scheduling phase, the two-level real-time scheduling algorithm is used. Each real-time container receives a fixed number of time slices within a main timeframe and allocates them to critical tasks within the container, ensuring that both real-time containers and critical tasks can run within foreseeable time slices. In the non-real-time processing environment scheduling phase, a priority-based non-preemptive scheduling algorithm is used, selecting the task in the container with the highest priority in the non-real-time processing environment for scheduling and execution. The number of time slices that each ordinary task can occupy after being scheduled in this phase can be configured. To ensure the determinism and stability of the main timeframe, if the remaining time slices of a single main timeframe are exhausted, the non-real-time scheduling phase ends immediately, and the general scheduling strategy continues only after the non-real-time processing environment scheduling phase of the next main timeframe begins.

[0034] This scheduling algorithm also supports multi-core scenarios, unifying the length and allocation of time slices across all physical cores running real-time scheduling. Container tasks within the same main timeframe cannot repeatedly exceed their time slice allocation by switching physical cores, nor will they lose time slices due to switching physical cores. Since switching processor cores for task execution can lead to performance instability, this solution defaults to binding each real-time container to a specific processor core. The multi-core capability of this algorithm is recommended only for use when the remaining time slice of a single processor core cannot meet the needs of the next real-time container to run, and for bundling it to a new processor core, rather than for multi-core switching after the real-time container has started.

[0035] The scheduling strategy of binding processing cores can make the internal environment of the scheduled processor more stable, reduce the failure of resources such as cache, and eliminate the overhead of synchronizing or transferring container task information on each core.

[0036] The specific steps for using the solution of this invention are as follows:

[0037] (1) Obtain the actual required scheduling blueprint, configure the first-level scheduling strategy in the second-level real-time scheduling in the containerized hybrid critical system, and establish the main time frame and container time frame: set the time of the main time frame, and set the execution order and execution time of each real-time container in each main time frame.

[0038] (2) Configure the second-level scheduling strategy in the second-level real-time scheduling in the scheduling blueprint: Based on the different criticalities, priorities, resource requirements, execution time and other factors of each task in each real-time container, set the scheduling order and execution time of each real-time task in the time frame corresponding to the container.

[0039] (3) Configure the number of time slices that each non-real-time task can occupy after being scheduled in the scheduling blueprint.

[0040] (4) Create and start the container, and the system runs according to the scheduling blueprint.

[0041] (5) If a real-time container is paused or exited during system operation, the system will automatically adjust the execution order and execution time of each real-time container in each main timeframe.

[0042] (6) If a real-time task is paused or exited during system operation, the system will automatically adjust the scheduling order and execution time of other real-time tasks in the container where the real-time task is located.

[0043] (7) If a non-real-time container or non-real-time task is paused or exited during system operation, the system will automatically adjust the scheduling and execution sequence of the non-real-time task.

[0044] To facilitate understanding, an example is provided below. As shown in Figure 3, the current blueprint configuration requires the system to run two real-time containers and several regular containers. Real-time container 1 is a single-task container, requiring 40 milliseconds of execution time every 200 milliseconds. Real-time container 2 requires 30 milliseconds of execution time every 100 milliseconds, with 10 milliseconds allocated to task 1 and 20 milliseconds to task 2. Therefore, the system sets the scheduler's time slice to 10 milliseconds and the main timeframe to 10 time slices. The first two time slices of each main frame are allocated to container 1 as its container timeframe, and the next three time slices are allocated to real-time container 2. Since real-time container 2 contains two tasks, the scheduler further follows the blueprint configuration, scheduling task 1 when the first time slice of the container timeframe arrives, and scheduling task 2 in the following two time slices. Thus, the scheduler achieves real-time guarantees for the real-time containers and their internal critical tasks. The remaining time slices in the main timeframe are used by the regular containers.

[0045] The above-described embodiments are merely one implementation of the present invention, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these all fall within the scope of protection of the present invention. Therefore, the scope of protection of this invention should be determined by the appended claims.

Claims

1. A hybrid scheduling method based on containerized hybrid key system, characterized in that, Critical tasks running in real-time containers use a two-level real-time scheduling algorithm based on period and time slice, while non-critical tasks running in non-real-time containers use an embedded general-purpose scheduling algorithm, which includes the following steps: Step 1: Obtain the actual required scheduling blueprint, configure the first-level scheduling strategy in the second-level real-time scheduling of the scheduling blueprint in the containerized hybrid critical system, and establish the main time frame and container time frame: set the time of the main time frame, and set the execution order and execution time of each real-time container in each main time frame; Step 2: Configure the second-level scheduling strategy in the second-level real-time scheduling of the scheduling blueprint: Based on the different criticalities of each task in each real-time container, set the scheduling order and execution time of each real-time task in the corresponding time frame of the container; Step 3: Configure the number of time slices that each non-real-time task can occupy after being scheduled in the scheduling blueprint; Step 4: Create and start the container; the system runs according to the scheduling blueprint. Step 5: During system operation, if a real-time container is paused or exited, the system will automatically adjust the execution order and execution time of each real-time container within each main timeframe. Step 6: During system operation, if a real-time task is paused or exited, the system will automatically adjust the scheduling order and execution time of other real-time tasks in the container where the real-time task is located. Step 7: During system operation, if any non-real-time containers or non-real-time tasks are paused or exited, the system will automatically adjust the scheduling and execution sequence of the non-real-time tasks.

2. The containerized hybrid key system based hybrid scheduling method of claim 1, wherein, The scheduling based on the main timeframe employs a periodic fixed-time-slice scheduling strategy: scheduling is performed in a fixed, periodic manner, using a round-robin mechanism as the basis. The scheduling order is statically set by configuring the period of the container being scheduled and the duration within that period, along with window scheduling within the main timeframe. To activate the round-robin, a main timeframe is maintained at a fixed period, enabling timed and repetitive execution. The main timeframe allocates a container window (i.e., a container timeframe) to each container, determining its offset within the main timeframe and its predetermined execution time. Each container can only execute at the specified time. During the time window configuration process, the execution sequence of the containers needs to be standardized.

3. The containerized hybrid key system based hybrid scheduling method of claim 1, wherein, The two-level real-time scheduling algorithm is an extension of the ARINC real-time scheduling algorithm, specifically designed for the multi-tasking characteristics of real-time containers, within the main timeframe. Specifically, under the current real-time scheduling algorithm's single main timeframe, time slices are first allocated to individual containers rather than the task threads within them, thus forming a container timeframe for each real-time container. Each real-time container, running within its own container timeframe, further performs a second level of real-time scheduling control over its tasks. This level of scheduling allocates time slices based on the pre-configured task timeframes for each task.

4. The containerized hybrid key system based hybrid scheduling method of claim 1, wherein, The hybrid scheduling strategy is based on the main timeframe and container timeframe design established by the first level of the two-level real-time scheduling algorithm. It completely isolates real-time container scheduling from non-real-time container scheduling in terms of time slices, ensuring preemptive scheduling of non-critical tasks for critical tasks. Specifically, within the main timeframe of the two-level real-time scheduling algorithm, scheduling is divided into two phases: a real-time processing environment scheduling phase and a non-real-time processing environment scheduling phase. In the real-time processing environment scheduling phase, the two-level real-time scheduling algorithm is used, and each real-time container obtains a fixed number of time slices within a main timeframe and allocates them to the critical tasks within the container. In the non-real-time processing environment scheduling phase, a priority-based non-preemptive scheduling algorithm is used, that is, the task in the container with the highest priority in the non-real-time processing environment is selected for scheduling and execution. The number of time slices that each ordinary task can occupy after being scheduled in this phase can be configured. To ensure the determinism and stability of the main timeframe, if the remaining time slices of a single main timeframe are exhausted, the non-real-time scheduling phase ends immediately, and the general scheduling strategy continues only after the non-real-time processing environment scheduling phase of the next main timeframe begins.

5. The containerized hybrid key system based hybrid scheduling method of claim 1, wherein, When the remaining time slice of a single processor core is insufficient to meet the needs of the next real-time container to run, it is bundled and run on a new processor core. This scheduling algorithm supports multi-core scenarios and unifies the length and allocation of time slices on each physical core running real-time scheduling.

6. The containerized hybrid key system based hybrid scheduling method of claim 1, wherein, This method binds a processor core to each real-time container by default.

7. The containerized hybrid key system based hybrid scheduling method of claim 1, wherein, In step 2, the criticality of each task includes its priority, resource requirements, and execution time.

Images