8
IEEE EMBEDDED SYSTEMS LETTERS, VOL. 6, NO. 1, MARCH 2014
HLC-PCP: A Resource Synchronization Protocol for Certifiable Mixed Criticality Scheduling Qingling Zhao, Zonghua Gu, and Haibo Zeng
Abstract—Today’s safety-critical Cyber-Physical Systems (CPS) often need to integrate multiple diverse applications with varying levels of importance, or criticality. Mixed-criticality scheduling (MCS) has been proposed with the objectives of achieving certification at multiple criticality levels and efficient utilization of hardware resources. Current work on MCS typically assumes tasks at different criticality levels are independent and do not share any resources (data). We propose highest-locker criticality, priority-ceiling protocol (HLC-PCP), which extends the well-known priority ceiling protocol (PCP) to be applicable to adaptive mixed-criticality (AMC), a variant of MCS. We present methods for worst-case blocking time computation with HLC-PCP, used for schedulability analysis of AMC with resource sharing. Index Terms—Cyber-physical systems, real-time scheduling .
I. INTRODUCTION Mixed criticality is the concept of allowing applications at different levels of criticality to interact and coexist on the same computational platform. The Air Force Research Laboratory (AFRL) established the mixed criticality architecture requirements (MCAR) program [1] in 2009, and identified mixed-criticality as a key research issue for avionics CPS. Sha [2] also emphasized the importance of mixed-criticality issues in complex CPS. In both avionics and automotive domains, there is a recent trend of hardware platform consolidation to move from many distributed small processors to a few centralized, large, and powerful processors, with benefits of reduced network traffic and increased system dependability. In order to address the challenges of integrating mixed-criticality systems on a shared hardware platform, researchers have proposed mixed-criticality scheduling (MCS), with the objectives of achieving certification at multiple criticality levels and efficient utilization of hardware resources. For the sake of strong functional and temporal isolation, current work on MCS typically assumes tasks at different criticality levels are independent and do not have any shared resources (data). While reasonable, Manuscript received April 27, 2013; accepted July 05, 2013. Date of publication July 15, 2013; date of current version February 24, 2014. This work was supported in part by the NSFC Project 61070002, the National 863 Project 2011AA010104, and the NSERC Discovery Grant RGPIN 418741-12. This manuscript was recommended for publication by Ramesh S. (Corresponding author: Z. Gu). Q. Zhao and Z. Gu are with the Department of Computer Science, Zhejiang University, Hangzhou 310013, China (e-mail:
[email protected]; zgu@zju. edu.cn). H. Zeng is with McGill University, Montreal, QC H3A 0G4 Canada (e-mail:
[email protected]). Color versions of one or more of the figures in this letter are available online at http://ieeexplore.ieee.org. Digital Object Identifier 10.1109/LES.2013.2273352
this assumption may be unnecessarily restrictive and conservative, since resource sharing between criticality levels is often necessary for today’s large and complex applications. In this letter, we propose highest-locker criticality, priority-ceiling protocol (HLC-PCP), which extends the well-known priority ceiling protocol (PCP) to be applicable to MCS, with bounded worst-case blocking time for its use in schedulability analysis. II. BACKGROUND AND RELATED WORK We briefly review adaptive mixed-criticality (AMC) [3]. Consider a set of independent and sporadic tasks . Each task is characterized by a tuple of , where is its period; is parameters its relative deadline; is its fixed priority assigned at design time (larger value denotes higher priority); is its criticality level; is a vector of worst-case execution time (WCET) estimates, one per criticality level, with the constraint that for any two distinct criticality levels and of task . In accordance with the current literature on MCS, and for convenience of notation, we assume the system is dual-criticality, i.e., there are only two criticality levels: low (LO) and high (HI). We use the abbreviations LO-crit and HI-crit to refer to LO-criticality and HI-criticality in this letter. Baruah et al. [3] introduced two variants of MCS if execution platform supports runtime monitoring and enforcement of task execution time limits: static mixed-criticality (SMC), where a LO-crit task is dropped (aborted) if it executes for more than its estimated WCET at LO-criticality level ; and adaptive mixed-criticality (AMC), where all LO-crit tasks are dropped (aborted) if any job (from any task ) executes for more than . Since [3] proved that AMC dominates SMC in terms of schedulability, we adopt AMC in this letter. It is important to distinguish between the criticality level of each task (LO or HI), denoted by the terms LO-crit task and HI-crit task; and the system-wide criticality level, denoted by the terms LO-crit mode and HI-crit mode. Lakshmanan et al. [4] presented two resource synchronization protocols for zero-slack scheduling (ZSS), another scheduling algorithm for mixed-criticality tasksets: priority and criticality inheritance protocol (PCIP) and priority and criticality ceiling protocol (PCCP). ZSS and AMC are quite different in terms of their design objectives and runtime rules, AMC aims to achieve certification at multiple criticality levels, while ZSS is not designed for certification. It offers asymmetric protection for higher-criticality tasks at the expense of lower-criticality tasks during system overload, but it does not guarantee that all deadlines are met even for tasks at the highest criticality level. Hence
1943-0663 © 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
9
ZHAO et al.: HLC-PCP: A RESOURCE SYNCHRONIZATION PROTOCOL FOR CERTIFIABLE MIXED CRITICALITY SCHEDULING
PCIP and PCCP designed for ZSS are not directly applicable to AMC.
is associated with a constant criticality Each semaphore ceiling , equal to the highest criticality of all tasks that can potentially lock it, as
III. HLC-PCP needs
A. Protocol Definition Consider a set of sporadic tasks, that access shared resources protected by a set of semaphores, . Each task is characterized by a tuple , with additional paof parameters rameters , and . is its fixed nominal priority assigned at design time, while is its active priority that may change dynamically at runtime according to PCP; is its fixed nominal criticality assigned at design time, while is its active criticality that may change dynamically at runtime according to HLC; is the set of semaphores used by . (We adopt the convention that notation for variables that can change at runtime starts with a lower-case letter; notation for constants starts with an upper-case letter.) We use the term HI-crit task to refer to a task with nominal criticality HI ( ); LO-crit task to refer to a task with nominal criticality LO ( ). Since some LO-crit tasks may continue to be active for sometime due to resource synchronization, in addition to the LO-crit and HI-crit modes in AMC, we need to consider an intermediate mode-change period (MCP), the time interval from the moment any task exceeds its , until all LO-crit tasks have been dropped and the system enters the HI-crit mode. Each semaphore is associated with a Priority Ceiling in LO-crit mode , defined as the highest priority of the tasks that can lock it in LO-crit mode needs
(1)
is also associated with a priority ceiling in HI-crit mode , defined as the highest priority of the tasks that can lock it in HI-crit mode, i.e., the tasks with nominal criticality HI needs
(2)
Each semaphore is associated with a dynamic priority ceiling , equal to the highest priority of the active tasks that can lock it; we define the set as the set of tasks that are not dropped. During mode-change period, this includes both HI-crit tasks, as well as LO-crit tasks that happen to be in their respective critical sections and cannot be dropped immediately if the critical section protects resources shared with HI-crit tasks needs
is currently active
(5)
The job dispatch rules for AMC with HLC-PCP are as follows: • R1: There is a system-wide criticality level indicator , initialized to LO. At any time, the system can be in one of three modes: LO-crit mode ( ); HI-crit mode ( ); Mode-Change Period ( ). During system execution, and when is not holding any semaphores. • R2: While ( ), at each instant the waiting job generated by the task with highest active priority is selected for execution. • R3: If the currently-executing job (from any task ) executes for without signaling completion, then the system goes into either Mode-Change Period ( ) if some LO-crit tasks are executing within a critical section protecting resource shared with HI-crit tasks; these tasks are dropped upon exiting their critical sections; when there is no more active LO-crit task, the system goes into HI-crit mode ( ). • R4: Once ( ), jobs with active criticality are dropped immediately. At each instant, the waiting job generated by the task with active criticality with the highest active priority is selected for execution. • R5: Task ’s active criticality is set to when enters a critical section by locking semaphore ; upon releasing , is restored to its original criticality value before locking . (The name HLC (Highest-Locker Criticality) derives from this rule.) • R6: To enter a critical section guarded by semaphore , must have priority higher than , where is the semaphore with the highest Dynamic Priority Ceiling among all the semaphores currently locked by active tasks other than itself. In addition, if a lower-priority task is holding a semaphore and blocks a higher-priority task that is trying to lock , then inherits the active priority of , i.e., . Theorem 1: HLC-PCP ensures that any critical section protected by semaphores needed by HI-crit tasks will always be completed, and not aborted. (Proof omitted)
B. Motivational Example (3)
Obviously,
in LO-crit mode; in HI-crit mode; during mode-change period. The Dynamic System Priority Ceiling dSPC is defined as the maximum dynamic priority ceiling of all semaphores currently held by active tasks is currently held
(4)
Consider the 4-task example in Table I. Task and need semaphore ; and need semaphore . contains a nested critical section: it locks and in order, and releases them in reverse order. ’s critical section protected by has maximum length 10; ’s nested critical section has maximum total length of 25; ’s critical section protected by has maximum length 10. Fig. 1 shows one possible schedule based on HLC-PCP. Here is a step-by-step description of the schedule in Fig. 1:
10
IEEE EMBEDDED SYSTEMS LETTERS, VOL. 6, NO. 1, MARCH 2014
TABLE I A MIXED-CRITICALITY TASKSET
• After time 80: continues to run, locking and releasing its needed semaphores and , since no other task contends for semaphores with it. C. Worst-Case Blocking Time Computation
Fig. 1. Possible schedule based highest-locker criticality-priority ceiling Pprotocol (HLC-PCP) for the example in Table I. Bold upwards arrows indicate task , and release times; thin upwards arrows indicate semaphore acquire . thin downloads arrows indicate semaphore release
• Time 0: is released and starts to run. Since no semaphore is locked, system priority ceiling ; ; . • Time 10: locks semaphore . System priority ceiling is raised to according to PCP; • Time 15: and are released. Since ’s priority is higher than and , and it is initially outside of its critical section, preempts and starts running. • Time 25: locks semaphore since its priority (3) exceeds the current system priority ceiling ( ), after which system priority ceiling is raised to according to PCP; ’s active criticality is raised from LO to HI ( ’s criticality ceiling ) according to HLC. • Time 30: is released and preempts . • Time 50: has run for 20 time units, its WCET estimate in the LO-crit mode , and has not finished yet, so the system experiences a mode change from LO to MCP. • Time 65: releases semaphore ; its active criticality drops back to LO, so it is aborted immediately according to AMC. Since no more LO-crit task is active, the system goes into HI-crit mode. Semaphore ’s dynamic priority ceiling drops from 3 to 2, since it is now only needed by task with nominal priority 2; System priority ceiling . Since has active priority ( ) higher than ( ), starts to run. • Time 75: requests semaphore . Even though is free, is blocked according to PCP, since its priority does not exceed of semaphore held by ; starts to run and inherits ’s active priority of 2. • Time 80: releases ; system priority ceiling drops to 0, but is raised back to 2 immediately when locks ,
We classify tasks other than itself into 4 categories, based on their nominal priority and criticality values: denotes set of HI-crit tasks with higher nominal priority than ; denotes set of LO-crit tasks with higher nominal priority than ; denotes set of HI-crit tasks with lower nominal priority than ; denotes set of LO-crit tasks with lower nominal priority than . Blocking occurs if a task that should be scheduled is actually not scheduled. In the context of MCS, blocking can be classified as either conventional priority-inversion blocking (pi-blocking), the conventional blocking term caused by a lower-priority task holding a resource needed by higher-priority task; or criticality-inversion blocking (ci-blocking), the new blocking term caused by a LO-crit task holding a resource needed by a HI-crit task during mode-change period. For schedulability analysis of an AMC taskset, we need to check 3 cases [3]: • Verifying schedulability of LO-crit mode by computing WCRT of each LO or HI-crit task , whose jobs are released and finished in LO-crit mode. In LO-crit mode, any task can experience pi-blocking from tasks in and . We use to denote the maximum pi-blocking time can experience within LO-crit mode. • Verifying schedulability of HI-crit mode by computing WCRT of each HI-crit task , whose jobs are released and finished in HI-crit mode. In HI-crit mode, a HI-crit task can experience pi-blocking from tasks in , since all tasks in have been dropped. We use to denote the maximum pi-blocking time can experience within HI-crit mode. • Verifying schedulability during mode-change period by computing WCRT of each HI-crit task , whose jobs are released in either LO-crit mode or Mode-Change Period, and finished in either HI-crit mode or Mode-Change Period, i.e., the job’s execution interval has some overlap with the Mode-Change Period. During this period, any HI-crit task can experience pi-blocking from tasks in and ; in addition, can also experience ci-blocking from tasks in . We use ( ) to denote the maximum pi-blocking (ci-blocking) time can experience within Mode-Change Period. Consider the example schedule in Fig. 1. In LO-crit mode, no task experiences any blocking; in HI-crit mode, experiences pi-blocking by in time interval [75, 80]; during Mode-Change Period, HI-crit tasks and both experience ci-blocking by LO-crit task in time interval [60, 65]. Note that delay caused by the first half of ’s critical section in time interval [25, 30] to and in the LO-crit mode is classified as preemption, since has higher priority than and ; but delay caused by the second half of ’s critical section in time interval [60, 65] to and during Mode-Change Period is classified as ci-blocking, since has lower criticality than and . (Note that all numbers here refer
ZHAO et al.: HLC-PCP: A RESOURCE SYNCHRONIZATION PROTOCOL FOR CERTIFIABLE MIXED CRITICALITY SCHEDULING
11
to actual blocking times in the example schedule, not worst-case blocking times.) We use to denote the longest critical section of task guarded by semaphore ; to denote the duration of . 1) Blocking time computation in LO-crit mode: Here, we consider a job of task released and finished in LO-crit mode
(6) Since can experience pi-blocking at most once, the maximum pi-blocking time that can experience in LO-crit mode is given by the length of the longest critical section among those that can block (7) 2) Blocking time computation in HI-crit mode: We consider a job of HI-crit task released and finished in HI-crit mode. It may experience pi-blocking only from tasks in , hence the maximum pi-blocking time that can experience in HI-crit mode can be obtained as (8) (9) 3) Blocking time during Mode-Change Period: Let denote the set of critical sections that can cause ci-blocking to , which include any critical section belonging to tasks in that is protected by semaphore with criticality ceiling HI (10) can experience ci-blocking at most once from each task that can block it. Identify each such that can cause ci-blocking to , then sum up the duration of the longest critical section among all the critical sections in that can cause ci-blocking to ; let be this sum (11) can experience ci-blocking at most once from each semaphore that can block it. Identify each semaphore that can cause ci-blocking to , then sum up the duration of the longest critical section among all the critical sections protected by that can cause ci-blocking to ; let be this sum (12) Let ( ) denote the total number of tasks (semaphores) that can cause ci-blocking to . Then can be blocked at most for critical sections, hence (13) As an example, consider in Table I. To compute its worst-case ci-blocking time, we first identify a single task in
Fig. 2. Percentage of schedulable tasksets versus taskset CPU utilization and critical section length.
, which locks a single semaphore . The analysis equations are very simple for this case with , where we have , length of the critical section in protected by semaphore . In LO-crit mode and during mode-change period, task can experience pi-blocking from tasks in and ; in HI-crit mode, a HI-crit task can only experience pi-blocking from tasks in , since all LO-crit tasks have been dropped. Hence . Furthermore, task can only experience ci-blocking during mode-change period. Hence, the maximum total blocking time is . IV. PERFORMANCE EVALUATION We generate random tasksets using similar techniques to [3]. Each taskset consists of 20 tasks. Each taskset has LO-crit mode utilization in the range of [0.05, 0.95], with increments of 0.05. For each utilization value, 1000 tasksets are generated that are schedulable by AMC-rtb [3] without any shared resources. We then add a global shared resource protected by a single semaphore; each task has a single critical section with length equal to a certain percentage (10% to 100%) of its . Task priority assignment follows Audsley’s optimal priority assignment algorithm. Fig. 2 plots the percentage of tasksets that are schedulable for different CPU utilizations and critical section lengths. As expected, schedulability decreases with increasing CPU utilization and/or increasing critical section length. Since realistic applications generally have short critical sections, the topmost curve with critical section length equal to 10% of is perhaps the most relevant, which indicates that the schedulability loss is within 10% for taskset CPU utilizations up to 80%. REFERENCES [1] J. Barhorst et al., A research agenda for mixed-criticality systems AFRL, Tech. Rep., 2009, vol. 11. [2] L. Sha, “Resilient mixed-criticality systems,” CrossTalk Mag., pp. 9–14, 2009. [3] S. K. Baruah, A. Burns, and R. I. Davis, “Response-time analysis for mixed criticality systems,” RTSS, pp. 34–43, 2011. [4] K. Lakshmanan, D. de Niz, and R. Rajkumar, “Mixed-criticality task synchronization in zero-slack scheduling,” RTAS, pp. 47–56, 2011.
