@article{eInformatica2018Art12,
 author = {Tarun Gupta and Erik J. Luit and Martijn M.H.P. van den Heuvel and Reinder J. Bril},
 title = {Experience Report: Towards Extending an OSEK-Compliant RTOS with Mixed Criticality Support},
 pages = {305--320},
 doi = {10.5277/e-Inf180112},
 year = {2018},
 volume = {12},
 number = {1},
 keywords = {OSEK, RTOS, mixed criticality},
 journal = {e-Informatica Software Engineering Journal},
 url = {http://www.e-informatyka.pl/attach/e-Informatica_-_Volume_12/eInformatica2018Art12.pdf},
 abstract = { \textbf {Background:} With an increase of the number of features in a vehicle, the computational requirements also increase, and vehicles may contain up to 100 Electronic Control Units (ECUs) to accommodate these requirements. For cost-effectiveness reasons, amongst others, it is considered desirable to limit the growth of, or preferably reduce, the number of ECUs. To that end, mixed criticality is a promising approach that received a lot of attention in the literature, primarily from a theoretical perspective.\ \textbf {Aim:} In this paper, we address mixed criticality from a practical perspective. Our prime goal is to extend an OSEK-compliant real-time operating system (RTOS) with mixed criticality support, enabling such support in the automotive domain. In addition, we aim at a system ({\em i\/}) supporting more than two criticality levels; ({\em ii\/}) with minimal overhead upon an increase of the so-called criticality level indicator of the system; ({\em iii\/}) requiring no changes to an underlying operating system; and ({\em iv\/}) featuring further extensions, such as hierarchical scheduling and multi-core.\ \textbf {Method:} We used the so-called adaptive mixed criticality (AMC) scheme as a starting point for mixed criticality. We extended that scheme from two to more than two criticality levels (satisfying ({\em i\/})) and complemented it with specified behavior for criticality level changes. We baptized our extended scheme AMC*. Rather than selecting a specific OSEK-compliant RTOS, we selected ExSched, an operating system independent external CPU scheduler framework for real-time systems, which requires no modifications to the original operating system source code (satisfying ({\em iii\/})) and features further extensions (satisfying ({\em iv}\/)).\ \textbf {Results:} Although we managed to build a functional prototype of our system, our experience with ExSched made us decide to rebuild the system with a specific OSEK-compliant RTOS, being $\mu $C/OS-II. We also briefly report upon our experience with AMC* and suggest directions for improvements.\ \textbf {Conclusions:} Compared to extending ExSched with AMC*, extending $\mu $C/OS-II turned out to be straightforward. Although we now have a basic system operational and available for experimentation, enhancements of the AMC*-scheme are considered desirable before exploitation in a vehicle. }
}