Experience Report: Towards Extending an OSEK-Compliant RTOS with Mixed Criticality Support
Journal Title: e-Informatica Software Engineering Journal - Year 2018, Vol 12, Issue 1
Abstract
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.
Authors and Affiliations
Tarun Gupta, Erik Luit, Martijn van den Heuvel, Reinder Bril
Keywords
Related Articles
- EP ID EP382529
- DOI 10.5277/e-Inf180112
- Views 65
- Downloads 0
On Visual Assessment of Software Quality
Development and maintenance of understandable and modifiable software is very challenging. Good system design and implementation requires strict discipline. The architecture of a project can sometimes be exceptionally di...
Experience Report: Introducing Kanban into Automotive Software Project
The boundaries between traditional and agile approach methods are disappearing. A significant number of software projects require a continuous implementation of tasks without dividing them into sprints or strict project...
Applying Machine Learning to Software Fault Prediction
Introduction: Software engineering continuously suffers from inadequate software testing. The automated prediction of possibly faulty fragments of source code allows developers to focus development efforts on fault-prone...
NRFixer: Sentiment Based Model for Predicting the Fixability of Non-Reproducible Bugs
Software maintenance is an essential step in software development life cycle. Nowadays, software companies spend approximately 45% of total cost in maintenance activities. Large software projects maintain bug repositorie...
Software Change Prediction: A Systematic Review and Future Guidelines
Background: The importance of Software Change Prediction (SCP) has been emphasized by several studies. Numerous prediction models in literature claim to effectively predict change-prone classes in software products. Thes...