In embedded operating systems (OSes), non-functional properties like reliability, performance, or memory footprint are of special importance. State-of-the-art OS product lines focus on the configurability of functional characteristics of the system. This chapter proposes an approach that aims at also making non-functional properties indirectly configurable and maintainable by the system configurator. In order to reach this goal, the CiAO OS product line used here has configurable architectural properties, which have no functional influence on the target system, but instead bear an impact on its non-functional properties. Additionally, the chapter develops a feedback approach that gains information about the non-functional properties of an already configured system to assist further configuration decisions, and presents and details the CiAO approach and evaluates it using two case studies from the CiAO operating system.
TopMotivation
In the domain of system software, non-functional properties (NFPs) are of fundamental importance to the end user. This is because system software never has a purpose and business value of its own, but it is rather a means to aid the application making use of it in fulfilling its (business-value-bringing) purpose. Hence, performance, for example, is an important non-functional criterion to select a suitable operating system (OS) to deploy an application on. In the sub domain of embedded operating systems, NFPs can even be mission-critical since some embedded systems applications depend on the fault tolerance or a given upper bound on the latency of the underlying embedded OS. Since the desired NFPs of a piece of system software are different from application scenario to application scenario (and sometimes reflect a trade-off decision), it is the task of the OS engineer to keep the NFPs configurable.
In our experience, though, the consideration of NFPs in system software causes problems because NFPs can never be made directly configurable. That is because most NFPs are emergent in their nature; that is, they have no direct representation in the system’s implementation entities. Instead, they result from the orchestration of the properties available in the selected configuration. Hence, NFPs can only be made configurable via indirect configuration of other properties.
However, the set of functional properties to be selected is fixed, dependent on the application. Other properties, which we call architectural properties (APs), are transparent to the application, though, but they still have an enormous effect on the NFPs of the resulting end system. Examples of such APs of OSes include the chosen method of interrupt synchronization in the kernel, the available protection facilities (including memory protection, for instance), or the type of interaction between kernel modules. The latter has been under heavy discussion for decades now, arguing in favor of procedural interaction in monolithic systems versus message passing techniques in microkernels (Lauer and Needham, 1979, Liedtke, 1995). The early decision to adopt one of those alternatives has a significant impact on the NFPs of performance, latency, and memory footprint, among others.
The CiAO family of embedded OSes developed by our research group was designed with architectural configurability in mind; that is, even fundamental architectural properties are kept configurable in CiAO’s design. Hence, the decision in favor of one or the other shape of an AP is postponed until the configuration stage and therefore left to the system configurator. He can then choose the one configuration option that has the best desired impact on the NFPs of the target system, effectively tailoring the OS (and its architecture) to the needs of the application scenario.
However, if the variability in a software product line exceeds a certain threshold (e.g., by offering architectural variability like in CiAO), the number of transparent configuration options left open to the configurator quickly becomes overwhelming. We therefore also propose a new kind of development process with a feedback approach, which gathers additional knowledge by analyzing product variants regarding their NFPs. It is thereby possible to assist the configurator in making his configuration decisions when aiming at optimizing a specific NFP.
The domain of embedded system software is one that has been concerned with non-functional properties for a long time being. Embedded systems engineers have gathered a lot of knowledge on how to deal with those properties, knowledge that the domain of service-oriented architecture can benefit from.
Structure of the Rest of the Chapter
The remainder of this chapter is structured in a top-down manner. First we give background information and definitions necessary for the understanding of the text. Then, an overview of our CiAO approach and, after that, its details are presented. The following section details the evaluation studies regarding the influence of APs on NFPs. We then present work that is related to our approach, and the chapter is concluded in the last section.