Extending a real-time operating system with a mechanism for criticality-level changes

Systems robustness, cost reduction and certification play an important role in the automotive domain. If there is a fault, e.g. task overshooting its allocated execution time, sufficient mechanisms should be available to safeguard the system against those. Applications of different criticalities (safety critical, mission critical and non-critical) are an integral part of modern automobiles. Typically these applications run on different and sometimes dedicated CPUs. One way of achieving cost reduction is to execute these applications on a single CPU (single core or multi core). This gives rise to issues pertaining to Mixed Criticality. Certification Authorities (CA) tend towards pessimistic worst case behavior e.g. Worst Case Execution Time (WCET) of safety and mission critical tasks. To meet the requirements of CA and scheduling requirements of mixed criticality tasks we introduce Criticality Levels. Criticality-levels determine the WCET of a task. The criticality-levels in which a task is operational are determined by the inherent criticality of a task. A safety or mission critical task needs more assurance for CPU time than a non-critical task. Hence at a higher criticality-level a non-critical task may not be allocated any execution time (meaning either aborted or suspended). Our idea is to associate tasks (and applications in future) to Criticality Levels and provide mechanisms for criticality-level changes