Partitioned Scheduling of Multi-Modal Mixed- Criticality Real-Time Systems on Multiprocessor Platforms

Transcription

1 Unversty of Pennsylvana ScholarlyCommons Departmental Papers (CIS) Department of Computer & Informaton Scence Parttoned Schedulng of Mult-Modal Mxed- Crtcalty Real-Tme Systems on Multprocessor Platforms Donso de Nz Lnh T.X. Phan Unversty of Pennsylvana, Follow ths and addtonal works at: Part of the Computer Engneerng Commons, and the Computer Scences Commons Recommended Ctaton Donso de Nz and Lnh T.X. Phan, "Parttoned Schedulng of Mult-Modal Mxed-Crtcalty Real-Tme Systems on Multprocessor Platforms", 20th IEEE Real-Tme and Embedded Technology and Applcatons Symposum (RTAS 2014). Aprl /RTAS th IEEE Real-Tme and Embedded Technology and Applcatons Symposum (RTAS 2014), Berln, Germany, Aprl Ths paper s posted at ScholarlyCommons. For more nformaton, please contact lbraryrepostory@pobox.upenn.edu.

2 Parttoned Schedulng of Mult-Modal Mxed-Crtcalty Real-Tme Systems on Multprocessor Platforms Abstract Real-tme systems are becomng ncreasngly complex. A modern car, for example, requres a multtude of control tasks, such as brakng, actve suspenson, and collson avodance. These tasks not only exhbt dfferent degrees of safety crtcalty but also change ther crtcaltes as the drvng mode changes. For nstance, the suspenson task s a crtcal part of the stablty of the car at hgh speed, but t s only a comfort feature at low speed. Therefore, t s crucal to ensure tmng guarantees for the system wth respect to the tasks crtcaltes, not only wthn each mode but also durng mode changes. Ths paper presents a parttoned mult-processor schedulng scheme for mult-modal mxed-crtcalty realtme systems. Our scheme conssts of a packng algorthm and a schedulng algorthm for each processor that take nto account both mode changes and crtcaltes. The packng algorthm maxmzes the schedulable utlzaton across modes usng the sustaned crtcalty of each task, whch captures the overall crtcalty of the task across modes. The schedulng algorthm combnes Rate-Monotonc schedulng wth a mode transton enforcement mechansm that reles on the transtonal zero-slack nstants of tasks to control low-crtcalty tasks durng mode changes, so as to preserve the schedulablty of hgh-crtcalty tasks. We also present an mplementaton of our scheduler n the Lnux operatng system, as well as an expermental evaluaton to llustrate ts practcalty. Our evaluaton shows that our scheme can provde close to twce as much tolerance to overloads (ductlty) compared to a mode-agnostc scheme. Dscplnes Computer Engneerng Computer Scences Comments 20th IEEE Real-Tme and Embedded Technology and Applcatons Symposum (RTAS 2014), Berln, Germany, Aprl Ths conference paper s avalable at ScholarlyCommons:

3 Parttoned Schedulng of Mult-Modal Mxed-Crtcalty Real-Tme Systems on Multprocessor Platforms Donso de Nz SEI, Carnege Mellon Unversty Lnh T.X. Phan Unversty of Pennsylvana Abstract Real-tme systems are becomng ncreasngly complex. A modern car, for example, requres a multtude of control tasks, such as brakng, actve suspenson, and collson avodance. These tasks not only exhbt dfferent degrees of safety crtcalty but also change ther crtcaltes as the drvng mode changes. For nstance, the suspenson task s a crtcal part of the stablty of the car at hgh speed, but t s only a comfort feature at low speed. Therefore, t s crucal to ensure tmng guarantees for the system wth respect to the tasks crtcaltes, not only wthn each mode but also durng mode changes. Ths paper presents a parttoned mult-processor schedulng scheme for mult-modal mxed-crtcalty real-tme systems. Our scheme conssts of a packng algorthm and a schedulng algorthm for each processor that take nto account both mode changes and crtcaltes. The packng algorthm maxmzes the schedulable utlzaton across modes usng the sustaned crtcalty of each task, whch captures the overall crtcalty of the task across modes. The schedulng algorthm combnes Rate-Monotonc schedulng wth a mode transton enforcement mechansm that reles on the transtonal zero-slack nstants of tasks to control low-crtcalty tasks durng mode changes, so as to preserve the schedulablty of hgh-crtcalty tasks. We also present an mplementaton of our scheduler n the Lnux operatng system, as well as an expermental evaluaton to llustrate ts practcalty. Our evaluaton shows that our scheme can provde close to twce as much tolerance to overloads (ductlty) compared to a mode-agnostc scheme. I. INTRODUCTION Today, t s common to structure the verfcaton of realtme systems based on layers of features of dfferent safetycrtcalty levels. For nstance, the automotve certfcaton standard ISO [15] dentfes four crtcalty layers (A- D) accordng to the safety crtcalty of the features. These layers are characterstcs of systems known as mxed-crtcalty systems, n whch hgher-crtcalty tasks must be gven hgher levels of assurance than lower-crtcalty tasks. At the same tme, modern real-tme systems are becomng ncreasngly adaptve. A modern car, for example, needs to adapt ts drvng mode dependng on the envronmental condtons, and each mode transton may requre actvatons of new tasks, deactvatons of exstng tasks, or changes of the crtcaltes of other tasks. Ths ncrease n safety requrements and adaptvty n real-tme systems ntroduces a new research queston: How to ensure tmng guarantees of tasks wth respect to ther crtcaltes not only n each mode, but also durng each mode transton? There exsts a rch lterature on mxed-crtcalty schedulng (e.g., [3], [4], [8], [18], [19], [23]) and mult-mode analyss (see [32] for a survey) for real-tme systems. However, to the best of our knowledge, exstng work does not consder mxed-crtcalty and mult-mode smultaneously. Ths paper ams to brdge ths gap by consderng the schedulng of mxed-crtcalty tasks n mult-modal systems. We use an automotve example that we defned out of features and drvng modes present n today s sport vehcles (e.g. actve suspenson) and real concerns from autonomous drvng researchers (e.g. pedestran detecton). Motvatng example. Consder an automotve system that executes four tasks on a two-processor platform: τ p (pedestrandetecton), τ s (suspenson-control), τ b (blnd-spot warnng), and τ a (ar-condtoner control). The system operates n three modes, Street, Hghway, IsolatedHOV 1, and the respectve crtcaltes of each task n these modes are as follows: τ p : Hgh, Low, Medum ; τ s : Low, Hgh, Hgh ; τ b : Hgh, Hgh, Low ; τ a : Low, Low, Low. In the above system, the crtcalty of a task and hence the crtcalty order between tasks changes when the system changes ts mode. Ths can lead to conflctng schedulablty requrements durng a mode transton. For nstance, τ p has hgher crtcalty than τ s n the Street mode but lower crtcalty than τ s n the Hghway mode; therefore, ensurng the schedulablty of τ p s more mportant n the Street mode, whereas guaranteeng the schedulablty of τ s s more crtcal n the Hghway mode. Ths conflct n the schedulng requrements ntroduces a new challenge: to acheve the schedulablty of τ p n the Street mode, t s necessary to delay or stop τ s durng overloads, but ths may make τ s unschedulable n the Hghway mode, f the system enters the Hghway mode after τ s has been delayed for too long. Another challenge s how to determne a good parttonng strategy that can protect hgh-crtcalty tasks from mssng ther deadlnes durng overloads. One promsng approach s to pack tasks that exhbt a mx of hgh and low crtcaltes nto each processor [19] to enable overbookng 2. However, n mult-modal systems, a packng that s desrable (.e., that enables overbookng) n one mode may become undesrable n another mode, and ths change happens dynamcally as the system executes n a sequence of modes. We demonstrate the above behavor usng the two packngs n Table I. In the table, tasks wthn each par of braces are assgned to the same processor and ther crtcaltes for each mode are shown n the correspondng mode column. It can be observed that P 1 has a good mx of hgh and low crtcaltes n the Street mode, but t has a poor crtcalty mx 1 In the IsolatedHOV mode, the vehcle travels n an solated lane, where no passng s possble. 2 Overbookng s the scheme that uses the scheduled executon budget of a hgher-crtcal task n excess of ts nomnal executon tme (.e., executon tme under overloads) to schedule lower-crtcalty tasks.

4 Mode s Crtcalty Mx Packng Street Hghway IsolatedHOV P 1 = {τ s, τ b }, {Low, Hgh}, {Hgh, Hgh}, {Hgh, Low}, {τ t, τ a} {Hgh, Low} {Low, Low} {Medum, Low} P 2 = {τ s, τ t}, {Low, Hgh}, {Hgh, Low}, {Hgh, Medum}, {τ b, τ a} {Hgh, Low} {Hgh, Low} {Low, Low} TABLE I MULTI-MODE MIXED-CRITICALITY PACKINGS ({Hgh, Hgh}; {Low, Low}) n the Hghway mode. Further, although P 1 becomes undesrable when the system swtches to the Hghway mode, t has a good crtcalty mx agan ({Hgh, Low}; {Medum, Low}) when the system enters the IsolatedHOV mode. In contrast, P 2 has a good crtcalty mx n both Street and Hghway modes, but ts crtcalty mx s worse than that of P 1 n the IsolatedHOV mode ({Hgh, Medum}; {Low, Low}) because the overloadng of τ s makes the medum-crtcalty task τ t mss ts deadlne nstead of a low-crtcalty task, as t happens n P 1. Contrbutons. Ths paper makes the followng contrbutons: We present a mult-modal task-to-processor packng algorthm that maxmzes the schedulable utlzaton across all modes. (Secton VI) We ntroduce the concept of transtonal zero-slack nstant that enables a mxed-crtcalty analyss durng mode changes, and we descrbe a method for computng these nstants. (Secton III-B) We present a mode transton enforcement scheme based on transtonal zero-slack nstants that ensures the absence of crtcalty volatons. (Secton IV) We present an mplementaton of our technque on the Lnux OS, along wth an experment llustratng ts practcalty. (Secton V) Our evaluaton on synthetc workloads shows that our schedulng scheme can save up to half the number of processors, and provdes much better protecton to hgh-crtcalty tasks durng overloads compared to a mode-agnostc scheme. (Secton VII) II. PROBLEM FORMULATION AND APPROACH OVERVIEW A. System model and problem statement A mult-modal mxed-crtcalty system s defned as S def = (Γ, P, M, Π), where Γ s the set of tasks, P s the set of processors, M s the set of modes, and Π M M s the set of mode transtons of the system. Each mode m M s assocated wth a set of tasks Γ m Γ that are actve n mode m. def Each task τ Γ s a perodc task, defned by τ = (C, C o, T, D, ζ ), where C, C o, T, and D are the nomnal executon tme, overload executon tme, perod, and relatve def deadlne of τ, respectvely. In addton, ζ = {ζ m m M τ Γ m }, where ζ m s the crtcalty of τ n mode m, for all modes m n whch τ s actve. Unlke tasks, jobs have fxed crtcaltes: the crtcalty of a job τ,k of τ s the crtcalty of τ wth respect to the mode n whch τ,k s released. Categorzaton of tasks. A task τ s called an old task of a mode transton (s, t) Π ff τ Γ s \ Γ t, a new task ff τ Γ t \ Γ s, and a persstent task ff τ Γ s Γ t. Snce the crtcalty of a persstent task τ may change across the transton, we vew t as beng made of two separate tasks, τ s and τ t, wth the same tmng parameters (C, C o, D, T ) but dfferent crtcalty: τ s has crtcalty ζ s and ts jobs are released n s but not n t, and τ t has crtcalty ζ t and ts jobs are released n t but not n s. We call the former an old-persstent task and the latter a new-persstent task of (s, t). Mode change semantcs. Each transton (s, t) Π s assocated wth a mode change request (MCR) that trggers the system to change ts current mode from s to t. We assume mmedate mode change semantcs for new tasks: as soon as the MCR of (s, t) arrves, all new tasks of the transton release ther frst jobs. In contrast, the frst job of each new-persstent task τ t of (s, t) s released exactly T tme unts from the last release of ts correspondng old-persstent task τ s pror to the MCR. Further, old and old-persstent tasks have no new releases, and jobs that have been released but not yet completed wll contnue to be executed after the mode change. We assume that MCRs may arrve at any tme; however, consecutve MCRs are separated enough so that they do not nterfere wth each other (whch s a common assumpton n exstng mult-mode work [32]). Mode transtons are nondetermnstc: f multple transtons are enabled at the same tme, the system non-determnstcally selects one. Crtcalty volaton. A crtcalty volaton s sad to occur when lower-crtcalty jobs prevent a hgher-crtcalty job from meetng ts deadlne 3 ; durng a mode transton, ths apples to only lower-crtcalty jobs that are (stll) actve after the MCR. Avodng crtcalty volatons, both wthn each mode and durng mode changes, s crucal to ensure tmng guarantees for hgher-crtcalty jobs. Objectves. Our goal s to desgn a schedulng scheme for mult-modal mxed-crtcalty systems that can maxmze the schedulable utlzaton 4 whle ensurng the absence of crtcalty volatons. Ths goal s drven by the strct rankng requrement of crtcalty: t s more mportant to guarantee the schedulablty of a hgher-crtcalty job than to guarantee the schedulablty of all of ts lower-crtcalty jobs. (As usual, a job s schedulable f ts deadlne s met, regardless of mode changes.) In ths paper, we focus on mplct deadlne tasks (.e., D = T ) for smplcty of dscusson; however, our method can easly be extended to explct deadlne tasks. B. Overvew of our approach Our mult-modal mxed-crtcalty multprocessor schedulng scheme conssts of () a mxed-crtcalty schedulng algorthm that schedules tasks on each processor, and () a mult-modal 3 Ths can be caused by a crtcalty nverson, whch s sad to occur when a lower-crtcalty job prevents a hgher-crtcalty job from executng. 4 Schedulable utlzaton s defned as the maxmum utlzaton under whch an algorthm can guarantee the deadlnes of any optmally-schedulable task, e.g., the schedulable utlzaton bound of the Rate-Monotonc algorthm s ln 2 for mplct deadlne perodc tasks.

5 bn-packng algorthm that assgns tasks to processors. We brefly ntroduce both below. The mxed-crtcalty schedulng algorthm schedules tasks on each processor usng a mult-mode extenson of the zeroslack rate-monotonc (ZSRM) schedulng [8]. Specfcally, jobs are scheduled accordng to the Rate-Monotonc (RM) algorthm; however, lower-crtcalty jobs wll be stopped at absolute zero-slack nstants of ther hgher-crtcalty jobs,.e., nstants from whch the hgher-crtcalty jobs must not be preempted by the lower-crtcalty jobs n order to meet ther deadlnes under an overload condton. The absolute zero-slack nstant of a job s the release tme of the job plus the (relatve) zero-slack nstant of ts task, whch s computed based on the task s (nomnal and overload) executon tmes and the nterference from hgher-prorty and hgher-crtcalty tasks. In contrast to unmodal systems, the crtcalty of a task can vary across modes; as a result, ts zero-slack nstant can be dfferent n each mode and n each mode transton. Our mxed-crtcalty schedulng scheme conssts of two phases: (1) at desgn tme, t computes the zero-slack nstants of each task n each mode (called n-mode zero-slack nstant) and n each transton (called transtonal zero-slack nstant); and (2) at runtme, t schedules tasks based on the RM algorthm, whle runnng an enforcement mechansm that stops lower-crtcalty jobs at the n-mode zero-slack nstant (when the system s n a mode) or at the transtonal zero-slack nstant (durng a mode transton) of a hgher-crtcalty job. Sectons III and IV dscuss these two phases n detal. The packng algorthm ams to maxmze the utlzaton of the system whle enablng overbookng n as many modes as possble. To acheve ths, t assgns tasks to processors based on both the tasks utlzatons n each mode and the tasks sustaned crtcaltes. Intutvely, the sustaned crtcalty of a task captures the overall crtcalty of the task across modes, whle ensurng that a hgher crtcalty s more mportant (.e., contrbutes more to the overall crtcalty) than all lower crtcaltes. Ths sustaned crtcalty provdes a unfed crtcalty value that can be used to determne how well a combnaton of tasks on a processor protects hgh-crtcalty tasks durng overloads across all modes of the system. We present the packng algorthm n Secton VI. III. MULTI-MODAL ZERO-SLACK INSTANTS A. Zero-slack nstant wthn a mode The zero-slack nstant of a task τ n a mode s, denoted by Z s, s computed n the same manner as n the sngle-mode ZSRM [8]. For convenence, we reproduce a summary of the computaton here and refer the reader to [8] for the detals. We start by restatng the schedulablty guarantee under ZSRM, as ths nfluences the amount of preempton suffered by a task. Under ZSRM, a task τ s guaranteed to execute for C o wthn ts perod T f no hgher-crtcalty task τ j executes for longer than C j. Ths guarantee has two mplcatons: Frst, τ s not guaranteed any computaton tme f any of ts hgher-crtcalty tasks τ j runs for more than C j ; as a result, n the computaton of Z s, every hgher-crtcalty task τ j s consdered to execute for only C j. Second, durng the calculaton of Z s, every task τ p wth a lower crtcalty but a hgher prorty than τ must be assumed to run possbly up to ts whole overload executon tme Cp. o Computaton of Z s. When the system s n a mode s, each job τ,k of τ executes n two states: t starts n the nomnal state, then swtches to the crtcal state when t reaches ts absolute zero-slack nstant (whch s ts release tme plus Z s). In the nomnal state, τ,k s scheduled wth all other tasks accordng to RM, regardless of ther crtcaltes; n the crtcal state, all tasks of lower crtcaltes than τ are stopped, and τ,k s scheduled wth only tasks of hgher crtcaltes, also accordng to RM. As a result, durng the nomnal state, τ,k can suffer preemptons from the nomnal nterferng taskset, denoted by Γ s,n, whch conssts of all tasks of hgher-crtcalty and all tasks of hgher-prorty and lower-crtcalty than τ n mode s. In contrast, durng the crtcal state, τ,k only suffers preemptons from the crtcal nterferng taskset, denoted by Γ s,c, whch conssts of only hgher-crtcalty tasks of τ n mode s. Furthermore, observe that the nterference caused by a lower-prorty hgher-crtcalty task τ j can only come from a sngle job τ j,h of τ j (snce the tasks are scheduled under RM and thus, τ j would have a longer perod than τ ); hence, we only need to account for ths nterference once. Snce τ j,h mght arrve durng ether executon state of τ,k, the worst case happens when τ j,h arrves durng the crtcal state of τ,k, as ths would be more lkely to make τ,k unschedulable. Based on the above nterference on τ, we can compute the zero-slack nstant Z s by frst assumng that τ runs completely n the crtcal state. We then compute the amount of slack (.e., the sum of the dle tme slots) n the actve nterval from the release tme to τ s deadlne, assumng that t runs n the nomnal state. Ths slack s used to move part of the executon of τ from the crtcal state to the nomnal state (thus, deferrng the Z s nstant). We then repeat ths process untl no more slack s found n the nomnal state, and the fnal value of Z s s the zero-slack nstant of τ n mode s. Preventng back-to-back hgh-prorty preemptons. In [14] the authors ponted out the possblty of back-to-back preemptons n the orgnal ZSRM [8]. Ths back-to-back preempton can be prevented wth a modfcaton to the orgnal enforcement n [8], whch s descrbed n Appendx A. B. Zero-slack nstant n a mode transton (s, t) Let τ be a task that s actve n mode s or n mode t,.e., τ Γ s Γ t. Observe that durng a mode transton (s, t), jobs of τ may experence nterference from both jobs that are released n mode s and jobs that are released n mode t. Therefore, t s not possble to ensure that τ does not experence a crtcalty volaton based solely on Z s and Z t. In ths secton, we propose a new concept, called transtonal zero-slack nstant, that can be used to guarantee the absence of crtcalty volatons for jobs durng a mode transton. Frst, we defne the transtonal nterval of (s, t) as the tme nterval from the nstant the MCR of (s, t) occurs untl

6 the earlest nstant at whch all jobs released n mode s have ether completed ther executons or mssed ther deadlnes. By defnton, the length of the transtonal nterval of (s, t) s always upper bounded by the maxmum relatve deadlne of all tasks that are actve n mode s (.e., max τ Γ s D ). Defnton 1. The transtonal zero-slack nstant of τ n a transton (s, t) s the maxmum amount of tme for whch any job τ,k of τ can be preempted by lower-crtcalty jobs wthout makng τ,k mss ts deadlne. The (absolute) transtonal zero-slack nstant of a job τ,k s ts release tme plus the transtonal zero-slack nstant of τ. Recall from Secton II that, f τ s a persstent task of (s, t), ts crtcalty may change across the transton. Therefore, we consder t as two separate tasks: an old-persstent task, whch has the old crtcalty and whose jobs are released n mode s, and a new-persstent task, whch has the new crtcalty and whose jobs are released n mode t. Snce the old-persstent task and the new-persstent task may have dfferent sets of lowercrtcalty tasks, we wll compute two dfferent transtonal zero-slack nstants for each persstent task τ of (s, t): the frst, denoted by Z st,old, wll be used to protect jobs of τ that are released before the MCR; and the second, denoted by Z st,new, wll be used to protect jobs of τ that are released after the MCR. 5 In contrast, f τ s an old task or a new task of (s, t), then t has one transtonal zero-slack nstant Z st, whch wll be appled to all of ts jobs. To compute these transtonal zero-slack nstants, we frst dentfy the nterferng jobsets of τ durng the transtonal nterval of (s, t). C. Interferng jobsets of τ durng a mode transton (s, t) Let τ,k be any job of τ that s actve durng the transtonal nterval of (s, t). Under our mult-modal mxed-crtcalty schedulng, τ,k operates n two states: t starts n the nomnal state and, when ts transtonal zero-slack nstant s reached, t swtches to the crtcal state. In the nomnal state, τ,k s scheduled wth all actve jobs; n the crtcal state, t s scheduled wth only hgher-crtcalty jobs. Below, we quantfy the jobs that nterfere wth τ,k n each state. Note that we only consder jobs whose release tmes or deadlnes are wthn τ,k s lfetme (wth maxmum length of T ). Interferng jobset of τ,k n the crtcal state: Its nterferng jobset effectvely conssts of only hgher-crtcalty jobs that are (stll) actve after the MCR. In other words, ths set conssts of () at most one job of each hgher-crtcalty task τ j of τ n mode s (.e., τ j Γ s,c ), and () all jobs of each hghercrtcalty task τ h of τ n mode t (.e., τ h Γ t,c ). Interferng jobset of τ,k n the nomnal state: The jobs that nterfere wth τ,k n ts nomnal state depends on τ s type: If τ s an old or old-persstent task: Then τ,k s released n mode s, and thus ts nterferng jobset conssts of () all jobs of each task τ j of hgher-crtcalty or hgher-prorty than τ n mode s (.e., τ j Γ s,n ) that are released before 5 For smplcty of exposton, we use the same notaton τ for both of ts correspondng old-persstent and new-persstent tasks, but dstngush the two by explctly referrng to ther task types. the MCR and () all jobs of each task τ h of hghercrtcalty or hgher-prorty than τ n mode t (.e., τ h Γ t,n ) that are released after the MCR. If τ s a new or new-persstent task: Then τ,k s released n mode t, and thus ts nterferng jobset conssts of () at most one job of each task τ j Γ s,n and () all jobs of each task τ h Γ t,n. Based on the above observatons, we can derve the maxmum crtcal/nomnal nterferng jobset of each task τ (to be appled to ts jobs n ther crtcal/nomnal states) by takng the largest set of nterferng jobs that any job of τ can experence durng ts lfetme. Algorthm 1 gves the pseudocode for computng the crtcal/nomnal nterferng jobset for each task τ that s actve durng the mode transton (.e., τ Γ s Γ t ) based on ts type. Specfcally, for each old or new task (Lnes 2 4 and 10 12), the algorthm computes one par of nterferng jobsets, J,c st, J,n st, to be used for computng Z st. In contrast, for each persstent task (Lnes 5 9), the algorthm computes two pars of nterferng jobsets, J st,old,c, J st,old,n and J st,new,c, J st,new,n, to be used for computng Z st,old and, respectvely. Z st,new n Algorthm 1 ComputeInterferngJobSets(Γ s, Γ t ) 1: for all τ Γ s Γ t do 2: f τ Γ s \Γ t then 3: J st,c GetOneJobPerTask(Γs,c ) GetJobsInInterval( 0, T, Γ t ),c 4: J st,n GetMaxHybrdJobSet(, Γ s,n, ) Γt,n 5: f τ Γ s Γ t then 6: J st,old,c GetOneJobPerTask ( Γ s (,c) GetJobsInInterval 0, T, Γ t ),c 7: J st,old,n GetMaxHybrdJobSet (, Γ s,n, ) Γt,n 8: J st,new,c GetOneJobPerTask ( Γ s (,c) GetJobsInInterval 0, T, Γ t ),c 9: J st,new,n GetOneJobPerTask ( Γ s (,n) GetJobsInInterval 0, T, Γ t ),n 10: f τ Γ t \Γ s then 11: J st,c GetOneJobPerTask( Γ s,c) GetJobsInInterval ( 0, T, Γ t,c 12: J st,n GetOneJobPerTask( Γ s,n) GetJobsInInterval ( 0, T, Γ t,n Algorthm 2 GetMaxHybrdJobSet (, Γ s,n, ) Γt,n 1: V s,n GetSlackVector(, Γ s,n, ) Zs 2: V t,n GetSlackVector(, Γ t,n, ) Zt 3: MCRI max 0 4: mnslack 5: SlackStarts GetSlackStartngs ( V s,n, V t ),n 6: for all p SlackStarts do 7: currentslack GetSlackInInterval ( 0, p, V s,n) + GetSlackInInterval ( p, T, V t ),n 8: f currentslack < mnslack then 9: mnslack currentslack 10: MCRI max p 11: return GetJobsInInterval ( 0, MCRI max, Γ s,n) GetJobsInInterval ( MCRI max, T, Γ t ),n In Algorthm 1, the crtcal nterferng jobsets for all tasks and the nomnal nterferng jobsets of new and new-persstent tasks are computed based drectly on the above dscusson. However, computng the nomnal nterferng jobset of an old or old-persstent task (Lnes 4 and 7) s more challengng, snce ths set hghly depends on the nstant at whch the MCR occurs. Snce ths nstant s unknown at desgn tme, we frst compute the worst-case MCR nstant, MCRI max, that leads to the maxmum nterference on a job of τ durng ts nomnal and crtcal states, and then use MCRI max to ) )

7 derve the worst-case nterferng jobset. Ths s done va the functon GetMaxHybrdJobSet, shown n Algorthm 2. (The key functons n Algorthm 2 are explaned n Appendx B.) Based on the computaton of the nterferng jobsets of τ, we can now derve ts transtonal zero-slack nstant(s). D. Computaton of transtonal zero-slack nstants Algorthm 3 shows the pseudocode for computng the transtonal zero-slack nstant Z st of each task τ, based on ts nterferng jobsets. Here, taskset (Lne 5) s the set of old, old-persstent, new, and new-persstent tasks of (s, t). That s, we mantan n taskset two separate tasks, old-persstent and new-persstent, for each persstent task of (s, t). Thus, the algorthm wll compute two separate transtonal zero-slack nstants for each persstent task of (s, t), as dscussed earler. Note that we use J,n st st and J,c to refer to the nomnal and crtcal jobsets of every task τ n taskset, ncludng when τ s an old-persstent task or a new-persstent task. Algorthm 3 ComputeTranstonalZeroSlackInstants(s, t) 1:, Z st,1 0 2: ComputeInterferngJobSets(Γ s, Γ t ) 3: repeat 4:, Z st,0 Z st,1 5: for all τ n taskset do 6: V st,n 7: V st,c 8: Z st,1 9: untl, Z st,0 10:, Z st st GetSlackVector(, J,n, Zst,0 ) st GetSlackVector(, J,c, Zst,0 ) GetSlackZeroInstant(, V st,n, V st,c, Zst,0 ) Z st,1 = Z st,1 At a hgh level, Algorthm 3 works as follows. It begns wth the worst-case assumpton that there s no slack n the nomnal state of each task, and each task always needs to run n the crtcal state. Then, t starts movng computaton tme from the crtcal state to the nomnal state as we dscover slack n the nomnal state (usng Algorthm 4). It then repeats the process wth the newly-computed zero-slack nstant. Note that, even though we only calculate the nterferng jobset at the begnnng of the algorthm, the proportons of computaton of the nterferng jobs that occur durng the nomnal state (C n ) and durng the crtcal state (C c ) change as we recalculate the zero-slack nstants (as we wll show n Algorthm 4). The algorthm converges when t cannot move the zero-slack nstant of any task towards ts deadlne. To acheve the above, the algorthm mantans for each task τ two varables, Z st,0 and Z st,1, whch store the zero-slack nstant values before and after an teraton, respectvely. Both Z st,0 and Z st,1 are ntalzed to zero (to ndcate that there s no slack n the nomnal state). In each teraton (Lnes 3 9), the algorthm frst calculates the slack vectors for τ n the nomnal and crtcal states (V,n st st and V,c ), based on τ s nomnal and crtcal nterferng jobsets (Lnes 6 7). Each slack vector contans a sequence of slack regons ordered by tme; each slack regon conssts of a startng nstant and a duraton. Based on the obtaned slack vectors, the algorthm then computes a new zero-slack nstant (Z st,1 the functon GetSlackZeroInstant(, V,n, V,c, Z st,0 ) for τ usng ). Wth the new zero-slack nstant, the algorthm proceeds to the next teraton and contnues n the same manner untl t converges (, Z st,0 = Z st,1 ). Algorthm 4 GetSlackZeroInstant(, V n, V c, t 0 ) 1: C c Co ; Cn 0 2: repeat 3: t 1 StartOfTralngSlack(, C c, Vc) 4: f t 1 0 and t 1 t 0 then 5: k u GetSlackInInterval(0, t 1, V n) C n 6: k u max(mn(k u, C c ), 0) 7: C c Cc ku 8: C n Cn + ku 9: else 10: k u 0 11: untl k u = 0 12: return t 1 Algorthm 4 shows the pseudocode for the functon GetSlackZeroInstant(, V n, V c, t 0 ). Intutvely, ths functon dvdes the overload executon tme C o of τ nto two parts: C c, the executon tme n the crtcal state, and Cn, the executon tme n the nomnal state. Intally, all executon tme s n the crtcal state (C c = C o ) and the crtcal state starts at tme t 0. The functon then repeatedly () computes a new startng tme t 1 for the crtcal state (Lne 3) usng StartOfTralngSlack(, C c, V c), whch gves the latest nstant where there are at least C c unts of slack wthn V c (the slack vector of τ n the crtcal state) that s before T, and then () moves the correspondng amount of executon tme (k u n Lnes 5 6) from the crtcal state to the nomnal state (Lnes 7 8). The algorthm termnates when no more computaton can be moved (k u = 0), and t returns the fnal value of t 1 as the new value for Z st,1 n Lne 8, Algorthm 3. Example 1. To llustrate the above computaton, consder a system wth two modes, s and t, that executes three (persstent) tasks: τ 1 = ( T 1 = 4, C 1 = 2, C1 o = 2.25, ζ1 s = 1, ζ1 t = 3 ) ; τ 2 = ( T 2 = 8, C 2 = 1, C2 o = 1, ζ2 s = 3, ζ2 t = 1 ) ( ; and τ 3 = T3 = 16, C 3 = 1, C3 o = 7, ζ3 s = 2, ζ3 t = 2 ). Recall that n the transton (s, t), each task τ has two transtonal zero-slack nstants, τ st,old and τ st,new. We wll llustrate the computaton of the transtonal zero-slack nstant Z st,old 3 of τ 3. Fgures 1(a), 1(b) and 1(c) depct the tmelne of τ 3 wth ts zero-slack nstants n mode s, n mode t, and n the transton (s, t), respectvely. A sold box represents an actual executon, whereas a dashed box represents an executon that would have happened f the task had not been preempted or stopped. To compute the nterferng jobsets of the old-persstent task τ 3 (c.f. Algorthm 1), we frst derve the worst-case MCR nstant MCRI max that leads to the maxmum nterference on τ 3 durng ts nomnal state and ts crtcal state (c.f. Algorthm 2). It can be observed from Fgures 1(a) and 1(b) that, durng the nomnal state, τ 3 suffers more nterference from τ 1 n mode s than n mode t. Ths s because τ 1 has lower crtcalty than τ 3 n mode s and thus, ts nterference ncludes all of ts overload executon tme (C1 o = 2.25); however, t has hgher crtcalty than τ 3 n mode t and hence, ts nterference ncludes only ts nomnal executon tme (C 1 = 2). Observe also that the nterference from τ 2 durng τ 3 s nomnal state s the same n

8 1/2 1/2 τ 1 LC 21/4 21/4 21/4 1/4 2 τ 1 HC τ 1 LC 21/4 21/4 11/2 MCRImax(10) 2 HC τ 2 HC 1 1 τ 2 LC 1 1 τ 2 HC 1 1 LC τ MC 3/4 13/4 3/ / τ MC τ MC 3/4 13/ MC 8 16 Z s 3 (121/4) t Z (10) 3 Z3 st,old (91/2) (a) Source Mode Tmelne (b) Target Mode Tmelne (c) Mode Transton Tmelne Fg. 1. Transtonal Zero-Slack Computaton Example both modes (snce C o = C ). Therefore, the nterference from τ 1 and τ 2 n mode s s larger than ther nterference n mode t. On the contrary, n the crtcal state, τ 3 experences more nterference n mode t than n mode s, because τ 2 s stopped n mode t (whch frees only 1 unt of executon) whereas τ 1 s stopped n mode s (whch frees 2 unts of executon). The above nterference patterns lead to the worst-case MCR nstant at the zero-slack nstant of τ 3 n mode t (MCRI max = 10), as shown n Fgure 1(c). Based on the obtaned MCRI max and the correspondng nterferng jobset of τ 3 n the nomnal state, usng Algorthm 3 we can derve the transtonal zeroslack nstant of τ 3 (Z st,old 3 = 9.5). IV. RUN-TIME SCHEDULING WITH ENFORCEMENT On each processor, our mult-modal mxed-crtcalty scheduler schedules tasks accordng to RM, and t uses an enforcement mechansm that stops (or drops) jobs based on the n-mode and transtonal zero-slack nstants of tasks. (The enforcement stops or drops a job followng the strategy n Appendx A, but we smply use the term stop for convenence.) Recall from the defnton of the transtonal nterval of a transton (s, t) that, from the end of the transtonal nterval onward, the system contans only jobs of new or new-persstent tasks (released n mode t). It can easly be shown that, f a job of τ s released after or at the end of the transtonal nterval of (s, t), the maxmum nterference t experences over any nterval s the same as the maxmum nterference a job of τ would have experenced n an nterval of the same length f the system had operated n a sngle mode t. Therefore, we can safely use the zero-slack nstants of tasks n mode t for the enforcement after the transtonal nterval; consequently, the transtonal zero-slack nstant s only applcable to jobs that are released before the end of the transtonal nterval of (s, t). Enforcement n a mode. After the system has transtoned to a mode s and the transtonal nterval has ended, enforcement works as follows: whenever an actve job of each task τ reaches ts n-mode zero-slack nstant Z s, all released jobs of tasks wth lower-crtcalty than τ n mode s are stopped. Enforcement upon an MCR. When the system s n mode s and the MCR assocated wth an outgong transton (s, t) arrves, the system wll enter the new mode (c.f. Secton II) and perform the enforcement nstantaneously. The enforcement s only performed on jobs that are actve durng the transtonal nterval of (s, t), and the specfc acton depends on whether the job arrves before or after the MCR. Specfcally, let MCRI be the arrval tme of the MCR wth respect to the release tme of an actve job τ,k durng the transtonal nterval. Then, the enforcement on τ,k works based on the transtonal zero-slack nstant Z st of τ,k as follows: If MCRI Z st, then the system mmedately stops all the jobs wth lower-crtcalty than τ,k. 6 If MCRI < Z st, then the system wats untl the transtonal zero-slack nstant Z st to stop all jobs wth lowercrtcalty than τ,k. The next lemma states the correctness of the enforcement; ts proof s avalable n Appendx C. Lemma IV.1. The above run-tme enforcement guarantees that no job experences crtcalty volatons. V. IMPLEMENTATION We mplemented our mult-modal zero-slack scheduler n a Lnux kernel module along wth a user-level lbrary to support the development of mult-modal mxed-crtcalty systems. An emprcal evaluaton of the run-tme overhead of our mplementaton s avalable n Appendx D. A. Modal system Our user-level lbrary provdes abstractons to buld modal systems that consst of a set of modal tasks and a system mode transton manager. A modal task, n turn, s composed of a collecton of modal job functons (one for each mode), a set of mode transtons, and an ntalzaton functon (nt()). A modal task s created by callng the functon start_modal_task() wth a modal task structure that contans ponters to the mode job functons, the nt() functon, and the mode transtons (to be dscussed shortly). Ths lbrary functon forks a process and returns the process ID of the newly-created process. The man body of a modal task frst calls the nt() functon and then nstalls the mode transton sgnal handler. After that, t enters an nfnte loop that executes the job functon repeatedly. In each teraton, the loop frst calls the job functon and then wats for the arrval of the next perod (wat_for_next_perod()) before callng the job functon agan 7. The sgnal handler functon s hdden 6 Note that f MCRI > Z st and the crtcalty of τ,k s lower than that of some new job(s) released after the MCR, then τ,k may not have enough tme to fnsh by ts deadlne f t executes for all of ts C o, due to nterference of these hgher-crtcalty new job(s). However, snce all actve lower-crtcalty jobs of τ,k are stopped, τ,k wll not experence a crtcalty volaton. 7 Whle our current mplementaton wats for the next perod, ths can be easly changed to a generc arrval trggerng functon that wats for external events, such as nterrupts.

9 perod elapsed & mode =1 watng next perod wat next perod mode 1 functon runnng wat next perod perod elapsed & mode =2 mode 2 functon runnng (a) Lbrary Fg. 2. sgnal arrved/ mode := sgnal_param sgnal handler perod elapsed watng next perod no mode change no suspenson requested check mode change runnng wat perod mode change / change reserve check suspenson (b) Scheduler Mode Change State Machnes mode change mode=suspend suspend mode change mode!= suspend change reserve suspenson requested nsde the runtme lbrary; t only changes the mode varable to the mode number that s sent by the mode transton manager. We make two mportant observatons about the mode change sgnal handlng: Frst, the sgnal handler runs nsde the modal task process under the schedulng parameters of that process; hence, t does not nterfere wth other tasks. Second, for tasks that are currently actve, the new mode s not effectve untl the next arrval of the job; that s, the lfetme of the current job (from the current tme to the next arrval) s not modfed. Instead, the new mode s regstered wthn the sgnal handler, whch wll be used upon the next arrval (wthn the wat_for_next_perod() functon). At the next arrval, the new job functon s executed, and the kernel scheduler then wats for the new perod of the task. 8 Ths behavor s llustrated by the fnte state machnes n Fgure 2(a). Mode transtons. Task mode transtons are part of the modal task structure, whch contans, for each transton, the source mode number, the target mode number, and the computed transtonal zero-slack nstant(s) (c.f. Secton III-B). The fnal modal system s composed of system modes and system mode transtons controlled by the system mode manager. System modes are composed of a collecton of task modes that each contan a process ID and a mode number. System mode transtons bundle tasks mode transtons. The system mode manager trggers system mode transtons by sendng mode swtch sgnals to each of the tasks, and then nstructs the kernel scheduler to start the transton, whch actvates the correspondng transtonal zero-slack nstants. The system mode manager runs as a persstent task across all modes, wth the hghest crtcalty and hghest prorty. B. Modal kernel scheduler The kernel scheduler s a reservaton-based scheduler that assgns modal zero-slack reserves to each task. A modal reserve s a collecton of regular zero-slack reserves along wth transtons. A modal reserve s frst created as an empty reserve, and then zero-slack reserves are created and added to the modal reserve. Once all the modal reserves have been created, the mode transtons are added wth ther correspondng transtonal zero-slack nstant(s). Fnally, a modal reserve s attached to a task upon ts creaton. A specal SUSPENSION mode s used to represent that 8 Our mplementaton allows tasks to change ther perods across modes. a task s nactve. The kernel scheduler uses ths mode to suspend the task when t needs to be dsabled n a partcular system mode. A task transtonng to the suspenson mode s dsabled at the next perod arrval (as expected). However, when a task transtons from the suspenson mode to an actve mode, the task s actvated mmedately, as requred by our mode change semantcs (c.f. Secton II). Ths s llustrated by the fnte state machne n Fgure 2(b). Our mplementaton uses a kernel scheduler thread that changes the prortes and the schedulng polcy of the tasks n response to schedulng events and the current mode, followng the strategy of the non-ntrusve kernel module n [9]. Ths kernel thread s necessary to avod changng the prorty nsde the tmer handler (trggered by an nterrupt) n the kernel module to avod deadlocks, snce changng the prorty modfes the prorty queues. Ths technque s also used n Lnux/RK [26] and a smlar kernel module scheduler n [17]. C. Mode change experment tmelne To show the effect of mode changes on our system, we created an experment wth three tasks (see Table II): a Suspenson task (τ s ), a Pedestran Detecton task (τ p ) and a (Coordnated) Cruse Control task (τ c ). Each task can run n two modes, Low Speed and Hgh Speed. We desgned the experment to focus our attenton on the zero-slack nstant of the task τ s, whch was calculated at 13s for both the mode transton and the target mode (Hgh Speed). Task T (s) C(s) C o (s) Crtcalty Low Speed Suspenson (τ s) Pedestran Detect. (τ p) Coord. Cruse Ctl. (τ c) TABLE II SAMPLE EXPERIMENTAL CAR TASKSET Fg. 3. Mode Change Tmelne (ms) Hgh Speed Fgure 3 shows the tmelne of a change from the Low Speed mode to the Hgh Speed mode n the expermental task. The X-axs shows tme (n msec), and the Y -axs shows the task that s actve at the correspondng tme (e.g., τ p s actve from 0 to 2000, as s shown by the sold bar that rses to τ p s marker). The mode change was requested roughly at tme t = 15s, whch s close to the end of the frst hyperperod (at t = 16s). We observe the followng effect of ths mode change request from the tmelne: Even though all old jobs have fnshed, the new jobs are only released at the next perods of the tasks (at t = 16s); ths s consstent wth our mode change semantcs for persstent tasks. In addton, when task τ s overruns ts zeroslack nstant at t = 29s (= 16s +13s), task τ p s stopped to let

10 τ s complete; ths llustratres the effect of the enforcement. It s worth hghlghtng that, around the same relatve tme from the start of the frst hyperperod n the source mode (.e., at t = 13s), τ p was not preempted by τ s, because τ p has hgher crtcalty and hgher prorty than τ s n the source mode. VI. MULTI-MODAL MIXED-CRITICALITY BIN-PACKING As dscussed n Secton II-B, the man objectve of our packng algorthm s to maxmze the utlzaton of the system whle enablng overbookng n as many modes as possble. Towards ths, we frst defne the sustaned crtcalty of a task τ as the overall crtcalty of the task across all modes, gven by: def = ( ) ζ m M + 1, (1) ζ m M where M s the set of modes of the system. Informally, each summand n Eq. (1) captures the degree of mportance (n terms of schedulablty requrements) of the task s crtcalty n each mode m. It s defned as the number of modes plus one to the power of the task s crtcalty n mode m, so as to preserve the strct rankng of crtcalty (.e., a hgher-crtcalty task s more mportant than any number of lower-crtcalty tasks). In addton, we defne the domnant crtcalty of τ as ts hghest crtcalty n all modes,.e., ζ = max m M ζ m. Algorthm 5 Mult-modal mxed-crtcalty packng algorthm. { 1: P {p 1, p 2,..., p k }, where k = max m M τ Γ m C } T 2: Γ rest 3: for all τ Γ n non-ncreasng ζ and non-ncreasng Co T do 4: deployed false 5: for all p j P n non-ncreasng fullness level of p m j where ζ m = ζ do 6: f overloaded(τ ) schedulable n overloaded(p j) then 7: deployed true 8: break 9: f deployed then 10: Γ rest Γ rest τ 11: for all τ Γ rest do 12: deployed false 13: whle deployed do 14: for all p j P n non-ncreasng fullness level of packed(p m j ) where ζ m = ζ do 15: f overloaded(τ ) s schedulable n packed(p j) then 16: deployed true 17: break 18: whle deployed do 19: P P new(p new) 20: f overloaded(τ ) schedulable n overloaded(p new) then 21: deployed true At a hgh level, the packng s performed by verfyng that the total requrements of the tasks allocated to a processor do not exceed the capacty of that processor. For ths, we descrbe the fullness level of a processor j as a vector p j = p 1 j, p2 j,..., p M j, where p m j s the fullness level of the processor n mode m, all for m M. The fullness vectors of the processors are then used together wth the sustaned and domnant crtcaltes of the tasks to order processors and tasks n our allocaton algorthm. We refer to ths algorthm as vector Mxed-Crtcalty Packng (vmcp), snce t s based on vector packng, wth processors modeled as vectors of capactes (one for each mode) and tasks modeled as vectors of requrements. The pseudocode for vmcp s shown n Algorthm 5. Algorthm 5 starts by creatng an ntal set of processors P whose combned capacty s equal to the largest taskset utlzaton across all modes (Lne 1). It then proceeds to the frst stage (Lnes 2 10), n whch t attempts to assgn tasks to the processors n a non-ncreasng order of sustaned crtcalty and utlzaton, assumng that each task τ runs for ts overload executon tme C o. In ths order, each τ s tred on each of the processors n P, ordered n non-ncreasng levels of fullness n the mode m wth the domnant crtcalty of τ (.e., ζ m = ζ ). The tasks that cannot be ftted on these processors are then set asde n a set Γ rest to be deployed n the second stage. In the second stage (Lnes 11 21), the algorthm deploys the tasks n Γ rest to the processors n P usng the same orders of tasks and processors as n the frst stage, but assumng that the tasks that have already been deployed n the frst stage only run for ther nomnal executon tmes (referred to as packed() n Lnes 14 15). If a task cannot be ftted onto any processor, a new processor s added (Lne 19), and the algorthm then tres to deploy ths task on the new processor, assumng that the task overruns (Lnes 20 21). It can be observed that the resultng packng always ensures all tasks are schedulable f the system does not overload. Note that Algorthm 5 follows a best-ft strategy when assgnng a task to a processor. However, t can easly be modfed to use other varants, such as frst-ft, worst-ft, etc. Due to space constrants, we omt them here. VII. EVALUATION In ths secton, we present an evaluaton of the proposed vmcp algorthm usng synthetc real-tme workload. Our goal s to evaluate how well the vmcp performs across dfferent crtcalty varatons of the system compared to a baselne mode-agnostc vector packng algorthm [7]. (To the best of our knowledge, there exsts no mode-aware packng algorthm for mult-modal mxed-crtcalty systems). A. Evaluaton metrcs: ductlty and resource use Observe that the conventonal schedulablty metrc cannot fully characterze the schedulng performance n a mxedcrtcalty system, snce two schedulers may both feasbly schedule the system under nomnal executon but one may guarantee more schedulable hgher-crtcalty tasks than the other under an overload condton. To address ths, we adapt the ductlty metrc [19] to evaluate the capacty of a scheduler n protectng hgh-crtcalty tasks durng overloads, whle extendng ths metrc to the mult-modal settng. Formally, let k be the number of dstnct crtcalty levels of the tasks n the system, and assume wthout loss of generalty that all tasks have crtcaltes between 1 and k. To defne the ductlty of a schedule n a mode, we consder all possble overloadng scenaros of tasks n each crtcalty level j. Each scenaro O l s a k-tuple O l = O l,k,..., O l,1, where O l,j = 0 f no tasks wth crtcalty j overload, and O l,j = 1 otherwse. (Snce there are k crtcalty levels, there are 2 k scenaros n total.) Correspondng to each overloadng scenaro O l, we defne for every crtcalty level j a ductlty value d l,j, whch

11 characterzes the possblty that all tasks wth crtcalty j meet ther deadlnes under the overloadng scenaro O l. That s, for all 1 j k, d l,j = 1 f all tasks wth crtcalty j are guaranteed to meet ther deadlnes under the overloadng scenaro O l, and d l,j = 0 otherwse. The ductlty of a schedule n a mode m can then be computed by aggregatng all of ts ductlty values d l,j n mode m, scaled by an order of magntude between crtcalty levels: ductlty(m) = k j=1 ( 2 k l=1 d l,j 2 kj + 1 The overall ductlty of a schedule of a mult-modal system s then gven as the sum of all the ductltes ductlty(m) for all modes m. It can be observed that ths ductlty metrc preserves the strct rankng semantcs of crtcalty, whle enablng comparson between dfferent schedules durng overloads. B. Workload In our experments, we frst generated fve dfferent types of harmonc perods 9, sampled from a unform dstrbuton between 100 and 1000, whch were used for all the tasks n our experments. For each generated perod, we selected the overloaded executon tme unformly at random between 10% and 30% of the perod. Fnally, the nomnal executon tme was selected unformly at random between 50% and 100% of the overloaded executon tme. Ths enables us to explore tasksets that do not suffer the nternal fragmentaton produced by heavy tasks (e.g., a task that can consume close to, or over 50% of the processor and ends up beng packed on a processor by tself) but stll allows for a reasonable amount of overbookng due to the dfference between the nomnal and the overload executon tme. Next, we generated all possble varatons of crtcalty-toprorty relatonshps. These relatonshps were encoded n a crtcalty vector, whose frst, second, and thrd entry represent the crtcalty assgned to the task wth the hghest, secondhghest, and lowest prorty, respectvely. In our experments, we used three modes and generated one crtcalty vector per mode. These vectors are shown on the X-axs of Fgure 4. (In the fgure, we only show a subset of the generated crtcalty vectors to hghlght nterestng cases where tasks wth dfferent prortes have dfferent crtcaltes.) C. Evaluaton results Resource savngs. Fgure 4 shows the number of processors needed under the vmcp algorthm and under the baselne vector packng wth respect to dfferent crtcalty vectors. The data presented n the fgure s the average of 100 experments. We observe the followng from the results: Frst, vmcp s able to reduce the number of requred processors, ndependent of the crtcalty vector. Ths s because vmcp s able to follow the sze of the tasks and the fullness of the processors accordng to the crtcalty, whereas the baselne algorthm frequently selects the wrong crtcalty (as t s agnostc to 9 Note that t s common for a system to have harmonc perods, such as Boeng avoncs [11] and ARINC 653 [1] systems. ). Number of Processors {0,1,2},{0,1,2},{0,1,2} Fg. 4. {0,1,2},{2,1,0},{0,2,1} {0,2,1},{0,2,1},{0,2,1} Vector Packng {1,0,2},{1,0,2},{1,0,2} {1,2,0},{1,2,0},{1,2,0} vmcp {2,0,1},{2,0,1},{2,0,1} {2,1,0},{2,1,0},{2,1,0} {2,1,0},{0,1,2},{2,0,1} vmcp vs Vector Packng Across Crtcalty Varatons crtcalty changes across modes). Second, unlke vmcp, the baselne packng uses more or fewer processors dependng on the algnment of the overall processor fullness across modes and the crtcalty of the task beng deployed; ths s the case for the second and the last columns. Fnally, n most crtcalty varatons, vmcp s able to reduce the number of processors by half, except for the two of the cases shown n the fgure (correspondng to the second and the last crtcalty vectors). Ductlty. In the second experment, we reduced the number of processors that the two packng algorthms were allowed to allocate, to compare how well they can preserve ductlty. Fgure 5 shows the ductlty values (normalzed to the maxmum possble for the taskset) that vmcp and the baselne vector packng algorthm can acheve for the same taskset f the number of processors that they are able to allocate s reduced. Ths fgure presents the average of 100 data ponts wth tasksets generated n the same fashon as n the prevous experment, wth the crtcalty vector {{2, 1, 0}, {0, 1, 2}, {2, 0, 1}}. Normalzed Ductlty Vector Packng vmcp Number of Processors Fg. 5. Ductlty vs. Number of Processors We can make three mportant observatons from Fgure 5: Frst, vmcp keeps a hgher ductlty n all data ponts. Second, the gap between vmcp and the normal vector packng ncreases at frst but later on becomes smaller, as the number of processors becomes too small to produce a sgnfcant dfference. Fnally, vmcp can acheve up to nearly twce the ductlty obtaned by the baselne vector packng algorthm. VIII. RELATED WORK Tmng analyss of mult-mode systems has been extensvely studed wthn the context of unprocessors (see e.g., [10], [12], [13], [27] [30], [32], [33], [35], [36]) and t has recently extended to multprocessor platforms [20], [21], [24], [25]. The prmary focus of ths lne of work has been on desgnng