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
Are We Working Well with Others? How the Multi Team Systems Impact Software Quality
Background: There are many studies on software development teams, but few about the interactions between teams. Current findings suggest that these multi-team systems may have a significant impact on software development...
Malicious JavaScript Detection by Features Extraction
In recent years, JavaScript-based attacks have become one of the most common and successful types of attack. Existing techniques for detecting malicious JavaScripts could fail for different reasons. Some techniques are t...
Data Flow Approach to Testing Java Programs Supported with DFC
Code based (``white box'') approach to testing can be divided into two main types: control flow coverage and data flow coverage. The data flow testing was introduced to structural programming languages and later adopted...
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...
Machine Learning or Information Retrieval Techniques for Bug Triaging: Which is Better?
Bugs are the inevitable part of a software system. Nowadays, large software development projects even release beta versions of their products to gather bug reports from users. The collected bug reports are then worked up...