I. Introduction
Real-time systems design is often aiming for providing guarantees for meeting deadlines in all possible scenarios. As a result, significant pessimism usually exists in real-time scheduling analysis and design. The system parameters, e.g., the needed execution time for a piece of code, are provisioned as upper bounds, which are often not tight, on the worst case. Consequently, while the system design and certification need to follow these pessimistic provisioned system parameters, computing resources might be significantly underutilized in practice due to the potentially huge gap between the general scenario during runtime and the worst-case provision used for analysis, design, and certification. One approach to mitigate such pessimism is mixed-criticality (MC) scheduling [11], [63]. Under MC scheduling, tasks are grouped to two distinct criticality levels—HI (stands for high criticality) and LO (stands for low criticality), and each system parameter might have two estimates—a more pessimistic one that provides an absolutely safe bound on even the worst-case scenario, and a less pessimistic one that covers a dominant majority of scenarios in practice (e.g., take the observed worst case in measurement-based experiments). An MC scheduler is designed based on the criticality levels and system parameter estimates, and needs to guarantee that the deadlines of all tasks (i.e., both HI- and LO-tasks) are met in "normal" scenarios in common practice while the deadlines of all HI-tasks are still met even if any pathological extreme cases do happen.