## 3 FENP_MC: Fixed Execution Non-Preemptive Mixed Criticality
### Perfectly Periodical Task Execution Model  
**Definition 1**.: _We say that the execution of task \(i\) is perfectly periodical if for each job \(k\) of task \(i\), \(J_{i}\), \(k\), the difference between the absolute start times of jobs \(k\) and \(k-1\) is constant:_  
\[s_{i,1}-s_{i,0}=s_{i,2}-s_{i,1}=\ldots=s_{i,n}-s_{i,n-1}=T_{i}. \tag{4}\]  
In order to exemplify a perfectly periodical execution algorithm, let us consider the task set presented in Table 1 that needs to be scheduled on a single-processor system, with two criticality levels (Low--Lo and High--Hi). In Table 1, \(T_{i}\) is the period of task \(i\), \(D_{i}\) represents the deadline, \(L_{i}\) is the criticality level, \(C_{i,L_{i}}\) expresses the computation time for the Lo-criticality mode and \(C_{i,L_{Hi}}\) is the computation time for the Hi-criticality mode \(C_{i,L_{Hi}}\).  
The start times of the tasks for the Lo-criticality case are depicted in Figure 1.  
In an MCS, Equation (4) must be true for all the criticality modes of the system (i.e., for all criticality levels), as shown in Figure 2, where \(P0_{Lo}\) represents low criticality and \(P0_{Hi}\) represents the high criticality level.  
In MCSs, different tasks with different criticality requirements share the same hardware; thus, in these systems, missing a deadline varies in severity from task to task [14]. In order to protect critical tasks from the interference of less critical ones, different levels of criticality are assigned to each task and different levels of assurance are provided for tasks running in different running scenarios, called criticality modes.  
As explained in [9], the classical model implies that the MCS starts in the lowest criticality mode. If all jobs behave according to the level of assurance imposed by this mode, then the system stays in that mode. On the other hand, if they attempt to execute for a longer time, then a criticality mode change occurs to a higher level of assurance.  
Next, we present an example where this mode change must occur and how FENP_MC treats the situation. Let us consider the task set presented in Table 2.  
\begin{table}
\begin{tabular}{c c c c c c} \hline
**Task** & \(T_{i}\) & \(D_{i}\) & \(L_{i}\) & \(C_{i,L_{Lo}}\) & \(C_{i,L_{Hi}}\) \\ \hline \(M_{1}\) & 10 & 10 & Lo & 3 & - \\ \(M_{2}\) & 20 & 20 & Hi & 2 & 4 \\ \(M_{3}\) & 30 & 30 & Hi & 5 & 6 \\ \hline \end{tabular}
\end{table}
Table 1: Three-task set example.  
Figure 1: Start times for the three-task set example in Lo-criticality mode.  
Figure 2: Scheduling the three-task set example in (**a**) Lo-criticality mode and (**b**) Hi-criticality mode.  
In Figure 3a, two scheduling tables are provided for two criticality modes (\(P0_{Lo}\) for the Lo-criticality mode and \(P0_{Hi}\) for the Hi-criticality mode, where Lo < Hi). The system starts in the Lo-criticality mode, using the \(P0_{Lo}\) scheduling table, but at Moment 4, task \(M_{2}\) exceeds its time budget allocated for the Lo-criticality mode, and that causes a criticality mode switch (see Figure 3b). The system continues to run according to the \(P0_{Hi}\) scheduling table, starting with the zeroth time instance. In this Hi mode, all Lo-criticality tasks are dropped, and only Hi-criticality tasks are scheduled according to their Hi level of assurance computation time.