- Tytuł:
- Experience Report: Towards Extending an OSEK-Compliant RTOS with Mixed Criticality Support
- Autorzy:
-
Gupta, T.
Luit, E. J.
van den Heuvel, M. M. H. P.
Bril, R. J. - Powiązania:
- https://bibliotekanauki.pl/articles/384148.pdf
- Data publikacji:
- 2018
- Wydawca:
- Politechnika Wrocławska. Oficyna Wydawnicza Politechniki Wrocławskiej
- Tematy:
-
OSEK
RTOS
mixed criticality
real-time operating system - Opis:
- 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. 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 (i) supporting more than two criticality levels; (ii) with minimal overhead upon an increase of the so-called criticality level indicator of the system; (iii) requiring no changes to an underlying operating system; and (iv) featuring further extensions, such as hierarchical scheduling and multi-core. 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 (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 (iii)) and features further extensions (satisfying (iv))). 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 µC/OS-II. We also briefly report upon our experience with AMC* and suggest directions for improvements. Conclusions: Compared to extending ExSched with AMC*, extending µ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. 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. 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 (i) supporting more than two criticality levels; (ii) with minimal overhead upon an increase of the so-called criticality level indicator of the system; (iii) requiring no changes to an underlying operating system; and (iv) featuring further extensions, such as hierarchical scheduling and multi-core. 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 (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 (iii)) and features further extensions (satisfying (iv))). 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 µC/OS-II. We also briefly report upon our experience with AMC* and suggest directions for improvements. Conclusions: Compared to extending ExSched with AMC*, extending µ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.
- Źródło:
-
e-Informatica Software Engineering Journal; 2018, 12, 1; 305-320
1897-7979 - Pojawia się w:
- e-Informatica Software Engineering Journal
- Dostawca treści:
- Biblioteka Nauki
Artykuł