Dynamic Constraints for Mixed-Criticality Systems

We define quality of service requirements for mixed-criticality systems based on min-plus algebra rather than discrete criticality levels. The requirements (1) unify a spectrum of weakly-hard real-time requirements with strongly-hard real-time and soft real-time as extreme cases and (2) support dynamic tuning of task importance. The paper elaborates the relation to mixed-criticality scheduling theory and weakly-hard real-time systems. The supported timing requirements, computational complexity, and scheduling feasibility are discussed.

Research on mixed-criticality systems (MCSs) -a term coined by Vestal [20] in 2007 -has accumulated a large body of results [3] as a way of providing performance guarantees for safe resource sharing among tasks of different importance.
Practical applicability of academic results on MCSs is being discussed and concerns have been raised [1,6,7]. WhRT concepts have been applied to provide degraded quality of service (QoS) for low-criticality tasks in overloaded MCSs [8]. We propose a new model of MCSs based on whRT concepts -rather than applying those concepts as an addition to an existing model.
Main contributions: We discuss a formulation of QoS requirements over the number of deadline misses. The proposed formulation has the following novel characteristics: • requirements are based on the min-plus algebra, which allows continuous control over dynamic parameters; • a spectrum of whRT requirements is unified with shRT and sRT as extreme cases. The following properties are discussed: • computational complexity is analyzed and a window-based approximation is suggested to make implementation feasible; • considerations for scheduling feasibility are outlined.
The paper is concerned with formulating effective requirements for MCSs and solving the resulting optimization problem is left for future work.

MOTIVATION
Our work is motivated by various aspects: robustness of MCSs (Section 2.1), providing whRT guarantees (Section 2.2), and supporting dynamic QoS requirements (Section 2.3).

Mixed-Criticality Systems
MCSs are associated with mixed-criticality scheduling theory (MC-Sched). Note, however, the more general topic of MCSs [1,3]. While we consider MCSs in the general sense, our motivation is based on MCSched and its limitations as follows.
MCSched was established by Vestal's seminal paper [20]. The considered task model is based on sporadic task systems as summarized in [3, Section 2]. A task system consists of tasks. Each task is defined by its period (minimal inter-arrival time), deadline, worstcase execution time (WCET), and criticality level (CL). Some, in rare cases indeed all, of the parameters have CL-dependent values (e.g., separate WCET estimates for CLs). Tasks generate a potentially unbounded sequence of jobs to execute.
The MCS -as in MCSched -starts running at its lowest CL mode and executes jobs for all tasks. At any CL mode, the system executes jobs for tasks with CL not below the current mode. When any executed job violates its CL-dependent WCET in the current mode, CL mode is raised to the next level; lower-CL jobs get ignored.
While there are different variants of the basic model depending on the properties of the parameters and the number of allowed CLs, all variants share common traits: MCSched is focused on a priori verification and its support for runtime robustness -the second aspect of safety-critical RT systems -is open to debate [1].
Abandoning tasks with lower CL and never returning to a low CL state is a major issue raised by systems engineers [1,6,7]. Some approaches mitigate the issue by reconfiguring the system to abandon tasks in a more graceful manner [3,Section 6].
Compliance to safety standards is important for industrial applications. The delicate connection between CLs and safety assurance levels (safety integrity level (SIL) in IEC 61508, automotive safety integrity level (ASIL) in ISO 26262, or development assurance level (DAL) in DO 178C) is discussed in [6] with arguments against the practical applicability of MCSched. The common ground of concerns is safety standards requiring separation among different assurance levels, which MCSched does not provide among CLs [3,6,7].
We also considered suggestions from [9] about safety assurance for MCSs, most importantly: need for partitioning integrity -that is temporal separation in our context -and problem formulation in terms of task importance -that describes the consequence of missing the deadline and varies dynamically.
This Work: We use a sporadic task model without CL-dependent values (i.e., values that are equal for all CLs): a MCS is defined based on task importance as individual QoS requirements, rather than statically-defined discrete CLs. We formulate task allocation with QoS requirements as constraints and realize partitioning integrity with respect to a minimal level of required service.

Weakly-Hard Real-Time Systems
ShRT systems require all deadlines to be met; sRT systems allow deadlines to be missed. sRT systems optimize some metric based on deadline misses but do not provide guarantees on bounding the number and distribution of deadline misses. WhRT systems bridge the gap between shRT and sRT systems by bounding the distribution of met and missed deadlines [2].
MCSched provides a priori verification of separate shRT models for each CL. While each CL is considered as a shRT system, switching between CLs renders MCSched a sRT system: allowing low-CL tasks to miss deadlines without bounds. While deadline misses are present in MCSs inherently, their distribution needs to be bounded for providing partitioning integrity.
This Work: We define MCSs as whRT systems by specifying QoS requirements as bounds on deadline misses. Fine-grained setting of task importance is supported by QoS parameters. The parameters unify a spectrum of whRT requirements including shRT and sRT as extreme cases.

Dynamic Quality-of-Service Requirements
Task importance in MCSs varies dynamically [9]. As far as we know, no MCS model with support for dynamic adjustment of task importance has been proposed yet.
This Work: We define dynamic QoS parameters to enable runtime adjustment of task importance. The QoS requirements are formulated based on the min-plus algebra [13], which allows continuous control of requirements by changing QoS parameters.

PRELIMINARIES
The section summarizes the model and notations for defining quality of service (QoS) requirements in Section 4: platform (Section 3.1) and task (Section 3.2) models, properties of jobs and their execution (Section 3.3) and QoS parameters (Section 3.4) are defined.

Platform Model
We model the platform as a set of processing elements (PEs), Π, with the effects of shared memory and the NoC being implicit. This abstraction limits accuracy without losing generality since QoS requirements are independent of those details. The same approach can be taken with full network on chip (NoC) and memory models to improve QoS guarantees.
We assume a discrete time model with time granularity δ = 1, which can be considered equivalent to one clock cycle of PEs.

Task Model
We follow the sporadic task model. A task, τ i , is defined by its minimal inter-arrival time, relative deadline, and PE-dependent worst-case execution time (WCET) as In the case of functional asymmetric multi-cores, Standard timing conditions (Eq. (1)) hold.

Jobs and their Execution
A task τ i generates a potentially infinite sequence of jobs, ι i, j , with properties inherited from τ i . A new job is generated at time A ι i, j , which is called the admission time of ι i, j . The absolute deadline of the job is then indicates if the job has been skipped, that is never released for execution.
An executed job ι i, j , for which S ι i, j = False, is mapped on a PE P ι i, j ∈ Π and scheduled to be released for execution at R ι i, j ∈ N + . Once a job starts to execute, it runs for completion; preemption is not supported. Note a natural restriction of task allocation: no PE may execute more than one job at any time.
The completion time C ι i, j of ι i, j is when the job signals completion. The execution time is No job is expected to execute longer than its WCET:

Parameters for Requirements
Requirements are derived from the following dynamic QoS parameters for each task τ i : is the allowed increase rate for non-bursting deadline misses to occur with; . . , B τ i } is allowed burstiness, the limit of consecutive deadline misses occurring in a burst.
The bounds M τ i , M τ i , and B τ i are static parameters of each task. The QoS parameters may change their value within their corresponding static bounds at any time. The actual dynamics of the parameters is dependent on application-specific factors beyond the scope of the model. Hence, the changes in the parameters are best perceived as stochastic disturbances.

QUALITY OF SERVICE REQUIREMENTS
The section specifies the actual requirements: basic definitions (Section 4.1), the QoS requirements (Section 4.2), and some necessary additional requirements (Section 4.3) are described.  2)).

Definitions for Quality of Service
The number of jobs generated by task τ i with absolute deadline not later than t is N τ i (Eq. (3)).
The delayed cumulative deadline miss function for task τ i starting at time s is M τ i ;s (Eq. (4)): the number of jobs that were generated by τ i and missed their deadlines between times s and s + t (an arbitrary period of the system's lifetime), including skipped jobs.
4.1.2 Deadline Miss Bounds. While QoS parameters S τ i ;M and S τ i ;b may change at any time, deadline miss bounds are derived on a job-by-job basis. The deadline miss bound for task τ i is based on the following parameters: • allowed increase rate of deadline misses for job • allowed burstiness of deadline misses for τ i at time t is (6)).
The delayed cumulative deadline miss bound for task τ i starting to count at time s is µ τ i ;s (Eq. (7)): the number of allowed deadline misses between times s and s + t for jobs generated by τ i ,

Quality-of-Service Requirements
QoS requirements are defined on the number of deadline misses. For respecting the QoS parameters (Section 3.4) both globally and locally, deadline miss requirements are defined by the convolution in min-plus algebra as in network calculus [13].
Min-plus algebra describes linear real-time (RT) systems; detailed description is available in standard textbooks, for example [13]. The min-plus convolution (⊗, Eq. (8)) can be used to calculate the output rate, a ⊗ s, of a service working with rate s and input arriving at rate a (i.e., rate a is bounded by s as a ⊗ s).
We set QoS requirements by bounding deadline misses, M τ i ;t , by the corresponding deadline miss bound function, µ τ i ;t , (Section 4.1). The actual number of deadline misses of task τ i is to be constrained by the bounded flow of deadline misses at any time t (Eq. (9)).
In analogy to network calculus, a flow of deadline misses is bounded by a deadline miss bound function as an arrival curve.
We have the inequalities in Eq. (10) as requirements.

Notion of Deadline Misses
As QoS is based on deadline misses, we briefly review different notions how deadlines may be missed according to [2]: delayed completion allows each job to run to completion even though it finishes after the deadline; abortion terminates any job that missed the deadline; skip allows the system to not release -skip -admitted jobs, the whole invocation is not executed; rejection allows the system to not admit -reject -jobs.
Our model allows jobs to be skipped but not to be aborted -as preemption is not supported (Section 3.3). Rejection is not applicable to our model because QoS requirements are defined over deadline misses of admitted jobs (Section 4.1).
Allowing delayed completion of released (i.e., not-skipped) tasks let more jobs to be completed at the cost of less room for utilizing dynamic power management (DPM) -features that are considered for future work (Section 5.5). Also, the value contributed by delayed completion is application-dependent. Hence, delayed completion is not included in our problem formulation.
We require all released jobs to meet their deadlines. Jobs that would not meet their deadlines are to be recognized before release and be skipped. This additional requirement is defined in Eq. (11).
As a job is either skipped or completed by its deadline and D τ i ≤ T τ i , not more than one job may be active -neither skipped nor completed -by the EPA of its consecutive job. Since job admission respects EPA times: at most one job may be active in the system for any task at any time.

PROPERTIES OF THE MODEL
The section discusses supported real-time (RT) requirements (Section 5.1), continuous control of dynamic requirements (Section 5.2), computational complexity (Section 5.3), scheduling feasibility (Section 5.4), and future work (Section 5.5).

Static Requirements
For catching supported RT requirements, consider static quality of service (QoS) parameters: S τ i ;M (t) and S τ i ;b (t) are invariant in t. No deadline misses are allowed for shRT tasks and sRT tasks may miss all their deadlines. An acceptable but bounded rate of deadline misses can be specified for whRT tasks between the extremes. Note that we call tasks between the two extremes (i.e., shRT and sRT) whRT tasks, though all requirements -including the extremesare expressed as whRT requirements.

Examples of Different
Inventory of the Supported Real-Time Requirements. The supported RT requirements are summarized in Table 1. Beyond the extreme cases of shRT and sRT, three types of whRT requirements are supported: whRT (1) covers a spectrum between shRT and sRT allowing deadlines to be missed regularly: it is 1 m as "misses any 1 in m deadlines" [2] where m = 1/S τ i ;M (t) ;  14), left axis) and QoS parameters (S τ i ;M (t) and S τ i ;b (t), right axis); periods when no deadline is missed let allowed burstiness replenish whRT (2) allows S τ i ;b (t) deadlines to be missed in total (the allowed burstiness never replenishes): it is S τ i ;b (t) + 1 as "misses row S τ i ;b (t)+1 deadlines" [2], also S τ i ;b (t ) ∞ stretching the definition of n m [2]; whRT (3) allows consecutive deadline misses limited by burstiness S τ i ;b (t), which depletes with every missed deadline and replenishes with rate S τ i ;M (t): it is ⟨ d + 1 ⟩ as "misses row d + 1 deadlines" [2] and д d+д as "meets any д in d + д deadlines" [2] where d (Eq. (12)) is the number of deadlines that may be missed consecutively until allowed burstiness depletes completely and д (Eq. (13)) is the number of deadlines that must be met consecutively for a depleted burstiness to allow one deadline to be missed.

Dynamic Requirements
For discussing dynamic QoS requirements, consider dynamic QoS parameters: S τ i ;M (t) and S τ i ;b (t) vary in t.
Tracking Dynamically Changing QoS Requirements. The actual number of deadline misses meeting requirements in Eq. (10) for task τ i is M τ i (Eq. (14)). The formula follows from properties of min-plus convolution (Eq. (8), [13]). Requirements in Eq. (10) makes M τ i follow changing QoS parameters (see Fig. 2) by enforcing deadline miss bounds (Eq. (7)) in all time windows.
Task Importance as QoS Parameters. Task importance as in [9] is an abstract metric of requirement specification; the metric is to be mapped to absolute whRT temporal requirements -QoS parameters -for implementation. Our model supports a spectrum of whRT requirements and allows dynamic changes -in line with [9].

Computational Complexity
Computing a convolution of t (e.g., M τ i ;s ⊗ µ τ i ;s (t)) has a time complexity of O(t). Computing QoS bounds (Eq. (9)) for one task up to t steps has a complexity of O( t w =0 w). Further, computing QoS bounds up to t steps for a task system of N tasks has a complexity of O(N t w =0 w). The sum ∞ w =0 w diverges for the infinite requirement in Eq. (10). We recognize that performing infinite computation would render any system infeasible. Note, however, that a corresponding partial sum of W steps has a closed form (Eq. (15)). A window-based approximation of QoS requirements has an overall complexity of O(NW 2 ) with a window of length W .
While approximating the QoS requirements is imperative for any implementation, we omit detailed discussion of window-based approximation due to space limitation. Conceptually speaking: full accuracy of approximation is being approached as window length -a design parameter -approaches infinity. That is because of a sliding window enforces local requirements; the longer the window, the longer a local requirement is respected.

Scheduling Feasibility
A system -platform and task set -is feasible concerning some requirements if a feasible task allocation -that satisfies the requirements -exists. A system is schedulable with an algorithm if the algorithm generates a feasible task allocation. Schedulability is a sufficient -but not necessary -condition of feasibility.

Feasibility.
Considering the strictest ("worst-case") requirements is sufficient to check feasibility of whRT systems with dynamic requirements.
Each task τ i is considered with QoS parameters S τ i ;M (t) = M τ i and S τ i ;b (t) = 0 -resulting in strictest requirements: • shRT tasks with M τ i = 0 must meet all their deadlines; • whRT tasks with 0 < M τ i < 1 may miss 1 in 1/M τ i deadlines (Section 5.1); • sRT tasks with M τ i = 1 are ignored.
They correspond to particular skip factors [12] and (m, k)-firm deadlines [10] according to [2,Section 3.3]. A necessary condition for feasibility of occasionally skippable task sets on uniprocessors has been given in [12,Eq. (2)]; while determining feasibility has been proven NP-hard [12,Theorem 3.2]. Schedulability checks for whRT task sets against a few scheduling algorithms have been discussed [2,11,12]. The published analyses consider scheduling algorithms that target uniprocessors with static requirements -properties that do not match our model.
Uniprocessor checks can be adapted for telling multiprocessor feasibility (sufficiently but not necessarily). A uniprocessor check is applied for each processing element (PE) for every possible mapping. The original complexity is increased by the exponential factor P (I +1) -depending on the numbers of PEs (P) and jobs (I ).

Schedulability.
The published scheduling algorithms for whRT systems ( [2,11,12]) lack support for multiprocessors and dynamic requirements. No algorithm that is applicable for the task allocation problem at hand is known to us -also see Section 6. Designing and implementing a suitable task allocation algorithm is left for future work.

Future Work
Our target is an energy-aware dynamic resource management technique for multiprocessor system on chip (MPSoC)-based mixedcriticality systems (MCSs). The discussed QoS requirements are merely a first step of a long journey with the following milestones: • complete analysis of the proposed QoS requirements on approximation (Section 5.3) and schedulability (Section 5.4); • a combined problem of task allocation and power management with -QoS requirements as constraints for partitioning integrity, -an energy-aware objective that simultaneously optimizes throughput and energy consumption; • an efficient resource manager for the problem with a windowbased approximation of QoS requirements and utilizing dynamic power management (DPM); • supporting communicating task pairs and communication over a network on chip.
Note that combining whRT requirements and dynamic power policies enables tuning between the contradictory goals of optimizing throughput and energy consumption. Dynamic parameters may be controlled by the appliances themselves based on the situation and system state -see self-adaptive systems [17].

Mixed-Criticality Scheduling Theory.
Our work is positioned with respect to mixed-criticality scheduling theory (MCSched) in Section 2. Works that provide runtime robustness for MCSched -see examples below -are limited by the basic model (Section 2.1).
Robustness of MCSs is discussed in the context of MCSched [4]. The severity of timing faults on the group of high-criticality tasks is analyzed. Tolerance against high-criticality task overruns and occasional skipping of robust tasks are utilized for graceful degradation.
Control theory has been applied [16] to implement runtime resilience for MCSched. The dual-criticality system is resilient against overruns of high-criticality tasks. Low-criticality tasks are not abandoned but may miss deadlines. Resource bounds can be calculated: QoS guarantees are synthetic properties of the integrated system.
WhRT requirements have been applied to MCSched [8] to reduce the load on the system. Some low-criticality tasks are skipped according to (m, k)-firm deadlines [10] when the system is in highcriticality mode -a degraded service instead of abandoning tasks. However, QoS (full or degraded) is unpredictable as being subject to occasional criticality mode switches.

Quality of Service.
The term QoS is used in many different areas. We consider QoS in relation to RT systems. The selected papers are also related to energy-awareness -a relevant aspect for future work.
Most of the papers consider QoS in combination with sRT systems, for example [5,14]. As sRT systems do not constrain deadline misses, QoS is used as a measure of "profit" that is realized by meeting deadlines. The overall "profit" is to be optimized. QoS for sRT systems does not define any absolute guarantees and hence no partitioning integrity is supported. Dynamic tuning of QoS requirements is typically not supported either.
On the other end of the RT spectrum, shRT systems do not allow flexibility in meeting deadlines. QoS is, nevertheless, used in some cases. For example, QoS classes are used to define the deadline of jobs generated by aperiodic tasks with varying workload [19].
A whRT system with QoS guarantee is described in [15]. QoS is defined as requirement of (m, k)-firm deadlines [10]. The proposed model is similar to ours: allowing fine-grained setting of whRT requirements and providing partitioning integrity accordingly. However, dynamic tuning of QoS requirements is not supported.

Weakly-Hard Real-Time Systems.
The whRT scheme of [2] generalizes other static whRT requirements [10,12,21]. The connection of the proposed QoS requirements to [2] is discussed in Sections 5.1 and 5.4.

CONCLUSION
We define QoS requirements for MCSs as dynamic whRT requirements based on the min-plus algebra. The QoS parameters unify a spectrum of whRT requirements with shRT and sRT as extreme cases. The fine-grained dynamic QoS requirements enable mixedcriticality (MC) problem formulation in terms of task importance. Continuous control over changing requirements is also supported.
The paper motivates and positions the proposed QoS formulation with respect to MCSched and whRT systems. Different properties of the requirements are discussed as well.
We recognize that an approximation of the described ideal QoS requirements is a necessity for implementation. Detailed discussion of a window-based approximation and a task allocation algorithm with schedulability analysis are left for future work.
Our final target is an energy-aware dynamic resource management technique for MPSoC-based MCSs. We consider the presented QoS requirements a basis for a relevant problem definition. We believe that providing proper partitioning integrity and support for dynamic tuning of requirements for both task importance and power policies -features we design our solution around -are going to be imperative for future smart embedded systems.