Task Allocation Techniques for Real-Time Mixed Criticality Multicore Systems: A Survey

Abstract

With the development of the Internet of Things and distributed systems, both the applications and the hardware support increased their complexity. This evolution resulted in an inevitable move toward multicore platforms at the edge of the Internet of Things in real-time and safety-critical systems. This shift to multicore architectures reflects also in the transformation and evolution of the mixed-criticality real-time task scheduling techniques, which still face several challenges due to their restricted resources and safety-critical aspects that include determinism, predictability, task isolation, resource management and low power consumption. The goal of this chapter is to present a survey on the state of the art multicore scheduling techniques, with a focus on task-allocation algorithms for mixed-criticality real-time systems, while identifying the research gaps and future trends.

Full text

Chapter
Task Allocation Techniques for
Real-Time Mixed Criticality
Multicore Systems: A Survey
Cristina-Sorina Stângaciu
Abstract
With the development of the Internet of Things and distributed systems, both the
applications and the hardware support increased their complexity. This evolution
resulted in an inevitable move toward multicore platforms at the edge of the Internet
of Things in real-time and safety-critical systems. This shift to multicore architectures
reflects also in the transformation and evolution of the mixed-criticality real-time task
scheduling techniques, which still face several challenges due to their restricted
resources and safety-critical aspects that include determinism, predictability, task
isolation, resource management and low power consumption. The goal of this chapter
is to present a survey on the state of the art multicore scheduling techniques, with a
focus on task-allocation algorithms for mixed-criticality real-time systems, while
identifying the research gaps and future trends.
Keywords: real-time, mixed-criticality systems, task scheduling, multicore
processors, partitioning
1. Introduction
In the context of the continuous development of the Internet of Things (IoT)
together with other types of distributed systems, the applications running on these
systems become more and more complex in order to satisfy the increasing demands of
communication, connectivity, varied functionalities and fast responsiveness. These
demands regarding functionality and performance, coming from the applications side,
are pushing forward the evolution of the hardware architectures that support them
[1, 2].
The complexity of the applications running at the edge of IoT or in other distrib-
uted embedded systems having a direct interaction with the environment, such as
cyber-physical systems, often imply both real-time and non-real time, critical and
non-critical interactions between these systems and the environment in which they
run [3]. This complex interaction led to conflicting requirements related to the com-
plexity of the applications, on one hand, and related to resource constraints imposed
by the end devices at the edge of IoT or by other embedded systems, on the other
hand. In order to deal with safety assurance and real-time functionalities, while
1

reconciling these conflicting requirements in the context of real-time and safety-
criticality systems, a new type of system was defined, named the mixed-criticality
systems (MCS). This concept defines systems with two or more criticality-level com-
ponents running on the same hardware. Their goal is to reconcile the need of
partitioning for safety assurance while still efficiently sharing resources [4].
MCS were initially developed in the context of automotive, [5] being the first
paper to formalize them. Since then, they were adopted in different fields, such as
cyber-physical systems [3], Industry 4.0 [6], avionics [7], and the Industrial Internet
of Things [8].
2. Organization
This chapter continues with the following sections: Section 3 presents the back-
ground and theoretical aspects regarding real-time systems in general, while Section 4
focuses on mixed-criticality systems, task modeling, execution behavior and schedul-
ing in multicore systems with a focus on task allocation. A methodology for mixed-
criticality task scheduling is proposed in Section 5 and the open issues are presented in
Section 6. This chapter ends by presenting the main conclusions in Section 7.
3. Background
The need to guarantee real-time services in critical environment led to the initial
proposal and formalization of the real-time systems (RTS) paradigm by Liu and
Layland in 1973 [9]. Real-time systems are defined as those systems for which not only
the correctness of the provided results is important, but also the time at which these
results are generated. Thus, special efforts have been made toward the development of
mathematical models, and scheduling methods in order to guarantee that all the time
constraints are respected.
According to the strictness of their time constraints (i.e., deadlines), the real-time
systems are classified into [10, 11]:
1.Hard RTS –in this class of systems, missing a deadline leads to a total system
failure (e.g., airbag system).
2.Firm RTS –infrequent deadline misses are tolerable, but the usefulness of the
result is zero after its deadline (e.g., traffic management).
3.Soft RTS –the usefulness of a result degrades after its deadline, leading to a
quality of service degradation (e.g., audio/video streaming).
A similar classification into hard, firm and soft extends to the software running on
these systems and includes the so-called tasks, which represent basic units of execu-
tion for each application running in a real-time system.
The classical real-time task models contain specifications about the time con-
straints of the tasks. Based on their arrival pattern, tasks can be periodic, sporadic or
aperiodic.
Periodic tasks are activated and executed within regular time intervals called
period. They are characterized by their execution time Cin the form of Worst Case
2
Computer Hardware Architecture –Essential Technologies for Modern Computing

Execution Time (WCET), period Tand relative deadline D, which can be equal to the
period if we consider implicit deadlines [9]. Each task must execute once and only
once in the interval between its activation time and its deadline. According to Liu and
Layland’s model proposed in Ref. [9], for a task τi, we have the following specifica-
tions:
τi¼Ci;Ti;Di
fg (1)
where Cirepresents the computation time, Tithe period and Dithe deadline for the
task τi.
If the activation of a certain task is done with an offset, relative to the system’s
activation time, a new parameter called phase ϕðÞis added [10–12]:
τi¼ϕi;Ci;Ti;Di
fg (2)
For task with no offset and implicit deadlines, the model could be simplified to the
following equation [9–12]:
τi¼Ci;Ti
fg (3)
From these parameters, others can be determined, such as the processor utilization
factor [9–12]:
Ui¼Ci=Ti(4)
Eq. (4), in fact, represents the definition of the processor utilization of a task.
Sporadic tasks are activated at arbitrary points in time, but with defined inter-
arrival times between two consecutive invocations. They are characterized by their
execution time Cin the form of Worst Case Execution Time (WCET), minimum
inter-arrival time Tand relative deadline D[13]. For a task τi, we have, the same
parameters as in Eqs. (1), (2) or (3), but with a different meaning for T.
Aperiodic tasks are activated at any point in time but only once. They are charac-
terized by their execution time Cin the form of Worst Case Execution Time (WCET),
arrival time Aand relative deadline D. For a task τi, we have:
τi¼Ci;Ai;Di
fg (5)
Each instance of a task is called job. In classical real-time systems, usually a job
inherits the parameters of the task it represents, but it can also be represented using
specific parameters, like in eq. (6) for a job jof task i:
τij ¼Cij;Aij ;dij
 (6)
where dij represents the absolute deadline, equal to Aij +Di. For a periodic task, with
no offset for its activation, Aij ¼j1ðÞ∗Ti.
An example of a task set execution on a single processor, simulated in SimSo [14],
can be seen in Figure 1. The task set consists of four tasks: T1 and T2 periodic, T3
sporadic, with an offset of 10, and T4 aperiodic, with the parameters represented in
eq. (7), according to Eq. (1) for T1-T2, Eq. (2) for T3, and Eq. (5) for T4:
T1¼3; 10; 10
fg
;T2¼4; 15; 15
fg
;T3¼10; 3; 20; 20
fg
;T4¼2; 13; 25
fg
; (7)
3
Task Allocation Techniques for Real-Time Mixed Criticality Multicore Systems: A Survey
DOI: http://dx.doi.org/10.5772/intechopen.1009825

In this figure, the up arrows represent the activation times and the down arrows
the deadlines.
Since their first introduction into the literature, real-time systems, together with
their programming and scheduling models, have become increasingly prevalent in
critical fields such as chemical factories, nuclear facilities, space exploration or mili-
tary applications [1], and in the relatively recent years these systems’integration
extended to fields like IoT, automated driving or healthcare [15].
4. Mixed-criticality real-time systems
Mixed-criticality systems are basically a type of real-time system where tasks are
valued by their criticality by classifying them into distinct levels of assurance against
failure, such as mission-critical and safety-critical [1, 4].
4.1 Task models and execution behavior
The classical real-time task model only specifies the temporal behavior of a job and
does not express its criticality, so new parameters were introduced. The first mixed-
criticality task model is considered the one proposed in 2007 by Vestal [5]. It repre-
sents a generalization of the sporadic task model introduces by Mok in 1983 [13].
Vestal’s model is characterized by four parameters: criticality level Liwhich range
from A to E (A being associated with catastrophic and E with no effect), period Ti,
deadline Diand computation time Cirepresented as a vector of WCETs, one for each
criticality level, usually ranging from the most optimistic value for the lowest critical-
ity level to the most pessimistic value for the highest one. Thus, the model from
Eq. (1), according to Vestal’s model [5], becomes:
Figure 1.
Example of uniprocessor real-time task set execution.
4
Computer Hardware Architecture –Essential Technologies for Modern Computing

τi¼Li;Ci¼Ci1;Ci2…CiN
fg
;Ti;Di
fg
(8)
where Liis the criticality level of task τi, and Ciis a vector of Nvalues, where Nis
equal to the order of the criticality level Li. Thus, a task of the lowest criticality level
will have only a value in the Civector, corresponding to its own criticality, a task of a
second criticality level (considered from low to high), will have two values and so on.
After Vestal’s task model, other generic models were proposed in the literature,
where other parameters are also vectors of values depending on criticality level.
Following the model proposed by Vestal, new models were developed. In MCS, the
software execution is also modeled at job level. Some of the most popular proposed
models and their characteristics are presented briefly in Table 1 from Appendix A,
where the criticality level, execution time, period and deadline are the same with the
ones expressed by Eq. (8), even if the notations are sometimes different as we can see
in the case of the criticality level expressed by L,l,χ,ζor kin the period expressed by
Tor p.
The majority of mixed-criticality models were created in an incremental manner
based on the structure proposed by Vestal as a generic model [5]. The models started
from the main four parameters: L—criticality level, T—period, D—deadline, C—
computation time and then were extended by adding parameters or by changing some
of the existing ones [15]. For example, some models include the activation time or
release time with the same meaning as the one expressed in Eqs. (5) and (6). Other
models add new parameters such as memory access time [16] or tolerable deadline
misses [17] while others consider parameters for task allocation in multi-core systems,
such as “designated core”[18] or “affinity score”[15], or other application or system-
specific parameters. Regarding criticality levels, some models reduce them to two
values: low (Lo)—that is, not critical and high (Hi)—that is, critical, while others
extend them to nlevels of criticality.
Changes were introduced also regarding the way in which computation time is
determined for each level and regarding the running modes of the tasks.
Computation times are usually determined from the most optimistic value for the
lowest criticality mode to the most pessimistic value, which guarantees the highest
criticality level of assurance. In MCS task executes in the lowest mode, considering the
computation time specific to that mode (optimistic value), if a task having a higher
criticality level than the current running mode, exceeds its computation time, and the
system switches to a higher running mode, in which lower criticality tasks are either
dropped, either scheduled in the remaining processor time, usually in a best-effort
manner.
In Figure 2, there is an example of a task set, consisting of three mixed-criticality
tasks, each having a different criticality level (T1 has a low criticality, T2 medium and
T3 high). The system starts in low criticality mode and runs in this mode until time
stamp 50, thus considering all the tasks for execution. The systems switches to
medium criticality mode at time stamp 50 and runs in this mode until 70, dropping
the low criticality task, and then switches in high criticality mode at 70, dropping all
other tasks except the high criticality one.
4.2 Scheduling in MCS
Task scheduling refers to the process of determining the order in which various
tasks are to be taken up for execution by a system. While traditional scheduling
algorithms are focused on throughput and fairness, real-time scheduling algorithms
5
Task Allocation Techniques for Real-Time Mixed Criticality Multicore Systems: A Survey
DOI: http://dx.doi.org/10.5772/intechopen.1009825

are focused on feasibility (i.e., whether or not it is possible to meet the requirements
of all the tasks) and predictability (i.e., the possibility to demonstrate that require-
ments are met subject to any assumption made) [11].
In multicore systems, the scheduling problem divides into two main sub-problems:
1.Task allocation—each task instance (i.e., job) must be allocated to a core
2.Task scheduling—each task (or job) set allocated to a certain core must be
feasible (i.e., schedulable)
In MCS, one must also take into consideration the spacial and time isolation
between tasks having different criticality levels. Time isolation is required to ensure
that a low criticality task cannot cause a higher criticality task to function incorrectly
by taking too much of processor time or by blocking a shared resource, while spacial
isolation is required in order to ensure that data used by a task is not altered by other
tasks and no tasks will adversely interfere with each other’s execution from this point
of view [2].
4.2.1 Task allocation
Task allocation in multicore environments is a relatively difficult problem and
most of the algorithms used in practice are heuristic [11, 19]. The task-allocation
algorithms can be classified into:
•Static—usually done at task level, all tasks are partitioned into subsets, each
subset is assigned to a core.
•Dynamic—usually done at job level, each task instance ready for execution is
placed in one common priority queue and dispatched to a core for execution,
when it becomes available.
Using multicore architectures in MCS brings several advantages regarding the
criticality levels temporal isolation issue. Thus, one popular static task-allocation
scheme is the one which considers the criticality level of tasks. The first one being
proposed by Andreson et al. in Ref. [20]. This schematic divides the task set into
Figure 2.
Example of uniprocessor mixed-criticality task set execution, containing three tasks, each having a different
criticality level.
6
Computer Hardware Architecture –Essential Technologies for Modern Computing

subsets of different criticality classes, which are then scheduled to different cores
using separate containers for each class, each container having its own local schedul-
ing algorithm.
Other approaches take into consideration, besides the classical utilization factor as
defined in Eq. (4), the load balancing [21], resource sharing [22], hardware heteroge-
neity [15], memory and cache management [23] or energy efficiency [24] or just the
schedulability conditions for the task subsets [25].
In MCS task-allocation algorithms, usually make use of classical real-time heuristic
methods such as first-fit, next-fit, best-fit or worst-fit [26, 27]:
•First-fit allocates each task to the first core it fits, considering the processor
utilization threshold.
•Next-fit allocates each task to the next core it fits, considering the previous task
allocation and the processor utilization threshold.
•Best-fit allocates each task to the core that maximizes the utilization factor, using
less cores.
•Worst-fit allocates each task to the core that minimizes the utilization factor,
giving a better load balance for the cores, compared to the other two approaches.
In the classical heuristics, the cores are selected in ascending order, or descending
order of their utilization, based on the heuristics mentioned earlier.
In mixed-criticality systems, these heuristics are adapted in order to take into
consideration, besides the utilization factor, one or more of the MC task parameters
presented in Table 1 from Appendix A. For example, Han et al. [28] proposed task-
allocation methods based on the task criticality level in conjunction with the worst-fit
heuristic and Stângaciu et al. [15] proposed a method based on task affinity in con-
junction with the best-fit heuristic. Other papers such as Ortiz et al. [26] proposed
their own partitioning methods based on the mixed integer linear programming algo-
rithm. Ren et al. [29] proposed a harmonic partitioning in conjunction with slack time
and compared it to all the other classical heuristics mentioned before, while Zhang and
Chen [30] proposed a partitioning method called energy-efficient allocating algorithm
(EEAA), which is based on the genetic algorithm.
On the other hand, the global scheduling approach makes decisions regarding job
assignment to different cores based on feasibility tests by checking sufficient
schedulability conditions at runtime [31].
Differences regarding the static and dynamic approaches can be seen in Figure 3,
where the same task set is allocated to different cores in a multicore system, using (a)
a static algorithm and (b) a dynamic one.
The task set consists of five periodic real-time tasks with the following parameters,
specified according to Eq. (1):
T1¼3; 10; 10
fg
;T2¼4; 15; 15
fg
;T3¼7; 10; 10
fg
;T4¼8; 25; 25
fg
;T5¼9; 10; 10
fg
;
(9)
In Figure 3(a), the tasks are allocated considering the maximization of the total
utilization factor. At the beginning, the total utilization on each core is 0; thus, task T1
can be assigned to any of the cores, but it is assigned to the last one, namely CPU 3.
7
Task Allocation Techniques for Real-Time Mixed Criticality Multicore Systems: A Survey
DOI: http://dx.doi.org/10.5772/intechopen.1009825

Task T2 is assigned to the core with the largest utilization factor that can accept task
T2 without exceeding a total utilization factor of 1 (i.e., 100%), which is CPU 3. Task
T3 cannot run on the same core, as the total utilization of tasks T1, T2 and T3 would
be greater than 1:
Figure 3.
Examples of multicore task allocation.
8
Computer Hardware Architecture –Essential Technologies for Modern Computing

Utot ¼X
3
i¼1
Ci=Ti¼0:3þ0:26ðÞþ0:7>1 (10)
Thus, task T3 is assigned to CPU 2. Because task T4 fits to CPU 3 (the core with the
highest utilization factor), it is assigned to this core, while the last task is assigned to
the only core it fits, namely CPU 1. In this example, this partitioning method provided
a total utilization of less than 1, on each core.
In Figure 3(b), there is an example of dynamic task allocation for the same task set
as in (a), in which each job is assigned to the core that is able to execute it before its
deadline. Thus, unlike the previous example, in this figure, we have tasks that have
some jobs executed on a core and other jobs executed on other cores, meaning that this
approach supports task migration.
4.2.2 Task scheduling
In a hierarchical multicore architecture, after the task-allocation procedure, a
scheduler is responsible for dispatching each task instance according to a predefined
algorithm.
Figure 4.
Examples of EDF-based MC task scheduling.
9
Task Allocation Techniques for Real-Time Mixed Criticality Multicore Systems: A Survey
DOI: http://dx.doi.org/10.5772/intechopen.1009825

The task scheduling is usually done at the core level using classical uniprocessor real-
time scheduling algorithms, such as cyclic executives, earliest deadline first (EDF), or
fixed priority (FP), specific MCS scheduling methods such as EDF-VD (EDF with
virtual deadlines) or CBEDF (criticality based EDF) [4] or hybrid [32]. A comparison
between two different approaches at the core level can be seen in Figure 4.
Other approaches imply hierarchical scheduling algorithms that contain fixed or
dynamic priority servers or containers, each one running a set of tasks or jobs. This
approach uses an algorithm for scheduling the containers, while each container can
implement its own scheduling algorithm for its allocated tasks [20].
Each real-time scheduling algorithm must provide a schedulability test or a meth-
odology for testing if a task set is schedulable by the algorithm. In the absence of a
dedicated schedulability test, one classical method is the response time analysis [33].
5. Methodology for MC task scheduling
In order to implement and schedule an MC application on a multicore system, one
can follow the steps depicted in Figure 5.
The procedure consists of the following main steps:
1.Develop the applications respecting the real-time programming paradigms,
which will result in the task set and its time specifications.
2.Assign a criticality level for each task and determine the MC task parameters
according to a selected model (e.g., Vestal’s model).
3.Choose a scheduling algorithm and analyze the schedulability of the task set with
the selected scheduling algorithm using a schedulability test or the response time
analysis approach.
Figure 5.
Example of uniprocessor mixed-criticality task set execution.
10
Computer Hardware Architecture –Essential Technologies for Modern Computing

4.Optional: schedule the task set, using an implementation of the selected
scheduling algorithm on a simulator.
5.Implement the scheduling algorithm (if not already implemented) on your target
system.
6.Schedule the application using the scheduling algorithm implementation on your
target system.
7.Optional: use a tracing tool or a logic analyzer and compare the task set
simulation with the actual application execution.
Different tools developed for RTS, such as aiT from AbsInt, which uses static
analysis for task WCET determination and formal verification [34], are still of great
use in MCS, especially for high criticality tasks. If we speak about low criticality tasks,
tracing and profiling tools such as Percepio Tracelayzer [35] could suffice.
Regarding the development of MC task schedulers, most of the work has been
done at the theoretical level. Even if there are numerous MC scheduling methods
proposed in the literature [33], there are very few implementations integrated into
operating systems. Some of the first to propose a multicore scheduling support imple-
mentation for MC tasks were Anderson et al. in Ref. [20]. This approach used an
extension of Linux called LITMUS RT [36]. Other proposed implementations for
multicore MC tasks using the same LITMUS RT extension followed [37, 38].
Before investing time and effort in implementing a specific scheduling algorithm,
running several simulations of that algorithm could be useful. Unfortunately for MCS
such simulator are currently missing. Ahmad et al. presented in 2018 [39] the top ten
most popular available real-time scheduling simulators with their advantages and
disadvantages. One remarkable fact is that none of the existing scheduling simulators
has support for mixed-criticality task scheduling. Still, some of them are designed to
be customized and extended. Such a simulator is SimSo [14].
Due to the lack of already implemented MC task schedulers in the current operating
systems, after analyzing and simulating the algorithms, one must implement them into
the running target system. Fortunately, Linux offers since 2024, a new kernel feature
called sched-ext [40], which enables the implementation of customized schedulers.
6. Open issues in MC multicore systems
On one hand, most of the development of the MCS has been done from the
theoretical point of view regarding execution and scheduling models, schedulability
and formal analysis. On the other hand, some progress was made regarding the
unification with the practical aspects of real-time systems, with the development of
customized scheduling support in Linux. Still, there are some open issues and imped-
iments regarding the large-scale practical implementation of MC systems and its
extension to more application fields, especially if we have in mind the complexity of
multicore systems:
•lack of simulators—the lack of support for MCS models and scheduling
algorithms simulation makes the development of practical applications difficult
and slow.
11
Task Allocation Techniques for Real-Time Mixed Criticality Multicore Systems: A Survey
DOI: http://dx.doi.org/10.5772/intechopen.1009825

•lack of custom schedulers support in current real-time operating systems—the
lack of support for any MC scheduling algorithm in the current operating systems
could be at least bypassed by the possibility to develop customizable scheduling
algorithms in decent time frame with a medium effort.
•lack of benchmarks for evaluation of MCS—the comparison of different MCS
models and scheduling approaches is done mostly at the theoretical level, and the
lack of a dedicated set of benchmarks contributes to the slow development of
these types of systems.
•lack of tools for real-time monitoring and control—tools for real-time monitoring
of the runtime behavior and comparison with the static analysis could also
accelerate the development of these systems.
7. Conclusions
Based on its extensions and applicability, the domain of mixed-criticality real-time
systems has become very important nowadays. As systems increase more and more in
complexity, it is imperative to have the possibility to have tasks with different levels
of criticality in the same hardware platform, while protecting the higher criticality
tasks from interferences from the lower levels.
The development of deterministic and power-efficient multicore platforms brings
advantages in terms of physical and temporal isolation for such systems, but also
increases the complexity of the scheduling methods, resulting in further development
of this field. As new mixed-criticality task models and schedulers are implemented,
the need for better support tools such as simulators and custom scheduling support
becomes more stringent.
Thanks
Special thanks to Andrei Briac, who developed an extension of the SimSo simulator for
mixed-criticality tasks, which was used to generate some of the examples from this
chapter.
Conflict of interest
The author declares no conflict of interest.
Abbreviations
CBEDF criticality based earliest deadline first
EEAA energy-efficient allocating algorithm
EDF earliest deadline first
EDF-VD earliest deadline first with virtual deadline
FP fixed priority
IoT internet of things
RT real time
RTS real-time systems
MC mixed criticality
12
Computer Hardware Architecture –Essential Technologies for Modern Computing

MCS mixed-criticality systems
WCET worst case execution time
A. Appendix
Reference Authors Year Task/Job Parameters Crit.
levels
[5] Vestal 2007 C–computation time (vector)
T–period (scalar)
D–deadline (scalar)
L–criticality level (scalar)
4
[41] Baruah, Li and Stougie 2010 A–release time (scalar)
D–deadline (scalar)
χ–criticality level (scalar)
C–computation time (vector)
2
[42] Park and Kim 2011 A–release time (scalar)
D–deadline (scalar)
χ–criticality level (scalar)
C–computation time (vector)
ES –empty slack (scalar)
2
[43] Su and Zhu 2013 C–computation time (vector)
p–period (scalar)
D–deadline (scalar)
L–criticality level (scalar)
pmax –maximum period (scalar)
Per –early release points (vector)
2
[44] Huang et al. 2013 C–computation time (vector)
T–minimum inter-arrival (scalar)
D–deadline (scalar)
L–criticality level (scalar)
n
[45] Ekberg and Yi 2016 job:
e–worst-case execution time (scalar)
d–deadline (scalar)
μ–mode of the corresponding job type (scalar)
4
[46] Zhou et al. 2017 T–period (scalar)
D–deadline (scalar)
N–number of transient faults (scalar)
L–criticality level (scalar)
C–computation time (vector)
2
[17] Lee and Shin 2017 C–computation time (vector)
T–period (scalar)
D–deadline (scalar)
L–criticality level (scalar)
m–tolerable deadline misses (vector)
n
[16] Li and He 2017 C–computation time (vector)
T–period (scalar)
D–deadline (scalar)
χ–criticality level (scalar)
E–execution time including memory access (vector)
M–memory access time (vector)
2
13
Task Allocation Techniques for Real-Time Mixed Criticality Multicore Systems: A Survey
DOI: http://dx.doi.org/10.5772/intechopen.1009825

Reference Authors Year Task/Job Parameters Crit.
levels
[47] Bletsas et al. 2018 C–computation time (vector)
T–period (scalar)
D–deadline (scalar)
k–criticality level (scalar)
λ–importance level (scalar)
2
[48] Wang et al. 2021 task:
C–computation time (vector)
T–period (scalar)
D–deadline (scalar)
ζ–criticality level (scalar)
V–value of task (vector)
job:
a–release time (scalar)
e–estimated execution (scalar)
d–absolute deadline (scalar)
f–finish time (scalar)
2
[15] Stângaciu et al. 2022 C–computation time (vector)
T–period (scalar)
D–deadline (scalar)
L–criticality level (scalar)
A–affinity score (scalar)
n
[49] Zhao et al. 2022 L–criticality level(scalar)
T–period (scalar)
D–deadline (scalar)
C_LO –WCET in LO-crit mode (scalar)
C_HI –WCET in HI-crit mode (scalar)
st –worst-case stack usage (scalar)
p–priority (scalar)
γ–preemption threshold (scalar)
2
[18] Chen et al. 2022 T–period (scalar)
D–deadline (scalar)
Pri –priority (scalar)
m–designated core (scalar)
l–criticality level (scalar)
C–set of WCETs (vector)
n
[50] Lesage et al. 2023 T–period (scalar)
C–execution time (vector)
L–criticality level (scalar)
P–priority (scalar)
CRP –cache recency profile (scalar)
2
Table 1.
Mixed-criticality task models.
14
Computer Hardware Architecture –Essential Technologies for Modern Computing

Author details
Cristina-Sorina Stângaciu
Politehnica University Timisoara, Timisoara, Romania
*Address all correspondence to: cristina.stangaciu@cs.upt.ro
© 2025 The Author(s). Licensee IntechOpen. This chapter is distributed under the terms of
the Creative Commons Attribution License (http://creativecommons.org/licenses/by/3.0),
which permits unrestricted use, distribution, and reproduction in any medium, provided
the original work is properly cited.
15
Task Allocation Techniques for Real-Time Mixed Criticality Multicore Systems: A Survey
DOI: http://dx.doi.org/10.5772/intechopen.1009825

References
[1] Ali A, Taj I, Iqbal S, Fayaz M,
Khattak AM, Hayat B. Mixed criticality
multicore compositional framework.
IEEE Access. 2024;12:129417-129433
[2] Cerrolaza JP, Obermaisser R, Abella J,
Cazorla FJ, Grüttner K, Agirre I, et al.
Multi-core devices for safety-
critical systems: A survey. ACM
Computing Surveys (CSUR). 2020;
53(4):1-38
[3] Capota EA, Stangaciu CS, Micea MV,
Curiac D-I. Towards mixed criticality
task scheduling in cyber physical
systems: Challenges and perspectives
2007. Journal of Systems and Software.
2019;156:204-216
[4] Burns A, Davis RI. A survey of
research into mixed criticality
systems. ACM Computing Surveys.
2017;50(6). DOI: 10.1145/3131347
[5] Vestal S. Preemptive scheduling of
multi-criticality systems with varying
degrees of execution time assurance. In:
28th IEEE International Real-Time
Systems Symposium (RTSS 2007). 2007.
pp. 239-243. DOI: 10.1109/RTSS.2007.47
[6] Simó J, Balbastre P, Blanes JF, Poza-
Luján J-L, Guasque A. The role of mixed
criticality technology in industry 4.0.
Electronics. 2021;10(3). DOI: 10.3390/
electronics10030226
[7] Yao J, Jiahong W, Liu Q, Xiong Z,
Zhu G. System-level scheduling of
mixed-criticality traffics in avionics
networks. IEEE Access. 2016;4:
5880-5888
[8] Cinque M, Cotroneo D, De Simone L,
Rosiello S. Virtualizing mixed-criticality
systems: A survey on industrial trends
and issues. Future Generation Computer
Systems. 2022;129:315-330
[9] Liu CL, Layland JW. Scheduling
algorithms for multiprogramming in a
hard-real-time environment.
Journal of the ACM (JACM). 1973;20(1):
46-61
[10] Buttazzo GC. Hard Real-Time
Computing Systems: Predictable
Scheduling Algorithms and Applications.
2nd ed. United States of America:
Springer; 2005. ISBN 0-387-23137-4
[11] Mall R. Real-Time Systems: Theory
and Practice. Pearson Education India;
2009. Available from: https://books.
google.ro/books?id=coPT7vaEjFsC&dq=
mall+real+time+2009&lr=&hl=ro&
source=gbs_navlinks_s
[12] Liu JWS. Real-Time Systems.
New Jersey: Prentice-Hall; 2000. ISBN
0-13-099651-3
[13] Aloysius Ka-Lau Mok. Fundamental
design problems of distributed systems
for the hard-real-time environment
[PhD thesis]. Massachusetts Institute of
Technology; 1983
[14] Chéramy M, Hladik P-E,
Déplanche A-M. Simso: A simulation
tool to evaluate real-time multiprocessor
scheduling algorithms. In: Proceedings of
the 5th International Workshop on
Analysis Tools and Methodologies for
Embedded and Real-Time Systems,
WATERS. 2014. Available from: https://
hal.science/hal-01052651v1
[15] Stângaciu CS, Capota EA,
Stângaciu V, Micea MV, Curiac DI. A
hardware-aware application execution
model in mixed-criticality internet of
things. Mathematics. 2022;10(9). DOI:
10.3390/math10091537
[16] Li Z, He S. Fixed-priority scheduling
for two-phase mixed-criticality systems.
16
Computer Hardware Architecture –Essential Technologies for Modern Computing

ACM Transactions on Embedded
Computing Systems. 2017;17(2). DOI:
10.1145/3105921
[17] Lee J, Shin KG. Development and use
of a new task model for cyber-physical
systems: A real-time scheduling
perspective. Journal of Systems and
Software. 2017;126:45-56
[18] Chen N, Zhao S, Gray I, Burns A,
Ji S, Chang W. Msrp-ft: Reliable resource
sharing on multiprocessor mixed-
criticality systems. In: 2022 IEEE 28th
Real-Time and Embedded Technology
and Applications Symposium (RTAS).
2022. pp. 201-213. DOI: 10.1109/
RTAS54340.2022.00024
[19] Mascitti A, Cucinotta T, Abeni L.
Heuristic partitioning of real-time tasks
on multi-processors. In: 2020 IEEE 23rd
International Symposium on Real-Time
Distributed Computing (ISORC). 2020.
pp. 36-42. DOI: 10.1109/
ISORC49007.2020.00015
[20] Anderson JH, Baruah SK,
Brandenburg BB. Multicore operating-
system support for mixed criticality. In:
Proceedings of the Workshop on Mixed
Criticality: Roadmap to Evolving UAV
Certification. Vol. 4. Citeseer;
2009. p. 7. Available from: https://www.
cs.unc.edu/~anderson/teach/comp790/
papers/2009-anderson-mcws.pdf.
[21] Yang C, Wang H, Zhang J, Zuo L.
Semi-partitioned scheduling of mixed-
criticality system on multiprocessor
platforms. The Journal of
Supercomputing. 2022;78(5):6386-6410
[22] Zhang Y-W, Ma J-P, Zonghua G.
Partitioned scheduling with shared
resources on imprecise mixed-criticality
multiprocessor systems. IEEE
Transactions on Computer-Aided Design
of Integrated Circuits and Systems. 2025;
44(1):65-76
[23] Bakita J, Ahmed S, Osborne SH,
Tang S, Chen J, Smith FD, et al.
Simultaneous multithreading in mixed-
criticality real-time systems. In: 2021
IEEE 27th Real-Time and Embedded
Technology and Applications
Symposium (RTAS). 2021. pp. 278-291.
DOI: 10.1109/RTAS52030.2021.00030
[24] Zhang Y-W, Chen R-K. A survey of
energy-aware scheduling in mixed-
criticality systems. Journal of Systems
Architecture. 2022;127:102524
[25] Capota EA, Stangaciu CS, Micea MV,
Cretu VI. P_fenp: A Multiprocessor Real-
Time Scheduling Algorithm. 2018. DOI:
10.1109/SACI.2018.8440932
[26] Ortiz L, Guasque A, Balbastre P,
Simó J. Allocation algorithms for
multicore partitioned mixed-criticality
real-time systems. Peer Journal of
Computer Science. 2024;10:e2609
[27] Liu H, Yang M, Wang T, Song C,
Zhu S, Chen X. A heuristic mixed real-
time task allocation of virtual utilization
in multi-core processor. Journal of
Information and Intelligence. 2023;1(2):
156-177
[28] Han J-J, Tao X, Zhu D, Aydin H,
Shao Z, Yang LT. Multicore mixed-
criticality systems: Partitioned
scheduling and utilization bound. IEEE
Transactions on Computer-Aided Design
of Integrated Circuits and Systems. 2018;
37(1):21-34
[29] Ren J, Jun Zhang X, Li WC, Li S,
Chu W, Song C. Enhanced harmonic
partitioned scheduling of periodic real-
time tasks based on slack analysis.
Sensors. 2024;24(17). DOI: 10.3390/
s24175773
[30] Zhang Y-W, Chen R-K. Energy-
efficient scheduling of imprecise mixed-
17
Task Allocation Techniques for Real-Time Mixed Criticality Multicore Systems: A Survey
DOI: http://dx.doi.org/10.5772/intechopen.1009825

criticality real-time tasks based on
genetic algorithm. Journal of Systems
Architecture. 2023;143:102980
[31] Li H, Baruah S. Outstanding paper
award: Global mixed-criticality
scheduling on multiprocessors. In: 2012
24th Euromicro Conference on Real-
Time Systems. 2012. pp. 166-175. DOI:
10.1109/ECRTS.2012.41
[32] Micea M-V, Stangaciu C-S,
Stangaciu V, Curiac D-I. Novel hybrid
scheduling technique for sensor nodes
with mixed criticality tasks. Sensors.
2017;17(7). DOI: 10.3390/s17071504
[33] Burns A, Davis RI. Mixed Criticality
Systems - A Review:(13th Edition,
February 2022). 2022. This is the 13th
version of this review now updated to
cover research published up to the end of
2021. Available from: https://eprints.
whiterose.ac.uk/183619/
[34] AbsInt Ait. Available from: https://
www.absint.com/ait/ [Accessed:
January 04, 2025]
[35] Percepio Tracealyzer. Available
from: https://percepio.com/tracealyzer/
[Accessed: January 04, 2025]
[36] Calandrino JM, Leontyev H,
Block A, Devi UMC, Anderson JH.
Litmus rt: A testbed for empirically
comparing real-time multiprocessor
schedulers. In: 2006 27th IEEE
International Real-Time Systems
Symposium (RTSS’06). 2006.
pp. 111-126. DOI: 10.1109/RT
SS.2006.27
[37] Herman JL, Kenna CJ, Mollison MS,
Anderson JH, Johnson DM. Rtos support
for multicore mixed-criticality systems.
In: 2012 IEEE 18th Real Time and
Embedded Technology and Applications
Symposium. 2012. pp. 197-208. DOI:
10.1109/RTAS.2012.2
[38] Pautet L, Robert T, Tardieu S.
Litmus-rt plugins for global static
scheduling of mixed criticality systems.
Journal of Systems Architecture. 2021;
118:102221
[39] Ahmad S, Malik S, Kim D-H.
Comparative analysis of simulation tools
with visualization based on real-time
task scheduling algorithms for iot
embedded applications. International
Journal of Grid and Distributed
Computing. 2018;11(2):1-10
[40] Sched-ext linux. Available from:
https://github.com/sched-ext/scx
[Accessed: January 04, 2025]
[41] Baruah S, Li H, Stougie L. Towards
the design of certifiable mixed-criticality
systems. In: 2010 16th IEEE Real-Time
and Embedded Technology and
Applications Symposium. 2010.
pp. 13-22. DOI: 10.1109/RTAS.2010.10
[42] Park T, Kim S. Dynamic scheduling
algorithm and its schedulability analysis
for certifiable dual-criticality systems.
In: Proceedings of the Ninth ACM
International Conference on Embedded
Software, EMSOFT’11. New York, NY,
USA: Association for Computing
Machinery; 2011. pp. 253-262
[43] Hang S, Zhu D. An elastic mixed-
criticality task model and its scheduling
algorithm. In: Design, Automation and
Test in Europe Conference and
Exhibition (DATE). 2013, 2013.
pp. 147-152. DOI: 10.7873/DATE.
2013.043
[44] Huang P, Kumar P, Stoimenov N,
Thiele L. Interference constraint graph—
A new specification for mixed-criticality
systems. In: 2013 IEEE 18th Conference
on Emerging Technologies and Factory
Automation (ETFA). 2013. pp. 1-8. DOI:
10.1109/ETFA.2013.6647967
18
Computer Hardware Architecture –Essential Technologies for Modern Computing

[45] Ekberg P, Yi W. Schedulability
analysis of a graph-based task model for
mixed-criticality systems. Real-Time
Systems. 2016;52:1-37
[46] Zhou J, Yin M, Li Z, Cao K, Yan J,
Wei T, et al. Fault-tolerant task
scheduling for mixed-criticality real-
time systems. Journal of Circuits,
Systems and Computers. 2017;26(01):
1750016
[47] Bletsas K, Awan MA, Souto PF,
Akesson B, Burns A, Tovar E.
Decoupling criticality and importance in
mixed-criticality scheduling. In:
Workshop on Mixed Criticality. York;
2018. pp. 25-32. Available from: https://
eprints.whiterose.ac.uk/140765/1/
WMC_2018_paper_Konst.pdf
[48] Wang W, Mao C, Zhao S, Cao Y,
Yi Y, Chen S, et al. A smart
semipartitioned real-time scheduling
strategy for mixed-criticality systems in
6g-based edge computing. Wireless
Communications and Mobile
Computing. 2021;2021(1):6663199
[49] Zhao Q, Mengfei Q, Huang B,
Jiang Z, Zeng H. Schedulability analysis
and stack size minimization for adaptive
mixed criticality scheduling with semi-
clairvoyance and preemption thresholds.
Journal of Systems Architecture. 2022;
124:102383
[50] Lesage B, Dai X, Zhao S, Bate I.
Reducing loss of service for mixed-
criticality systems through cache-and
stress-aware scheduling. In: Proceedings
of the 31st International Conference on
Real-Time Networks and Systems. 2023.
pp. 188-199. DOI: 10.1145/
3575757.3593654
19
Task Allocation Techniques for Real-Time Mixed Criticality Multicore Systems: A Survey
DOI: http://dx.doi.org/10.5772/intechopen.1009825