Project Initiatives

An operating system is located between two fronts: On the one hand ("above") the machine programs of the applications with their sometimes very different functional and non-functional requirements and on the other hand ("below") the computer hardware, whose features and equipment ideally are to be made available "unfiltered" and "noise-free" for the applications. However, a general purpose system cannot be as efficient in any of its functions as a system designed specifically for a specific purpose, and less demanding applications may require that they are not forced to pay for the resources consumed by the unneeded functions. So it is not uncommon for large systems, once put into operation, to be subject to frequent changes --- precisely in order to achieve a better fit to changing application requirements.

The ideal operating system offers exactly what is required for the respective application --- no more and no less, but also depending on the characteristics of the hardware platform. However, such an ideal is only realistic, if at all, for an uni-programming mode of operation. In the case of multi-programming, the various applications would have to have "sufficiently the same" functional and non-functional requirement characteristics in order not to burden any of the applications with the overhead that the unneeded functions entail. An operating system with these characteristics falls into the category of special purpose operating system, it is tailored to the needs of applications of a certain type.

This is in contrast to the general purpose operating system, where the ultimate hope is that an application will not be burdened with excessive overhead from the unneeded functions. At least one can try to minimise the "background noise" in the operating system if necessary --- ideally in this case with a different "discount" depending on the program type. The operating system would then not only have to be dynamically freed from unnecessary ballast and shrink with less demanding applications, but also be able to grow again with more demanding applications with the necessary and additional functions. Specialisation of an operating system depending on the respective application ultimately means functional reduction and enrichment, for which a suitable system software design is desirable, but often can no longer be implemented, especially with legacy systems.

One circumstance for the specialisation of an operating system relates to measures explicitly initiated "from outside". On the one hand, this affects selected system calls and, on the other hand, tasks such as bootstrapping and the loading of machine programs, operating system kernel modules or programs that are to be executed in sandbox-like virtual machines within the operating system kernel. This form of specialisation also enables the dynamic generation of targeted protective measures as a result of particularly vulnerable operating system operations, such as loading external modules of the operating system kernel. The other determinant of the specialisation of an operating system relates to measures initiated implicitly "from within". This concerns possible reactions of an operating system to changes in its own runtime behavior that are only noticeable during operation, in order to then adapt the strategies of resource management to the respective workload and to seamlessly integrate the corresponding software components into the existing system.

The project focus is the dynamic operating system specialisation triggered by extrinsic and intrinsic events. The focus is on concepts and techniques that (a) are independent of a specific programming paradigm or hardware approach and (b) are based on just in time (JIT) compilation of parts of the operating system (kernel) in order to to be loaded on demand or to be replaced anticipatory to the respective conditions on the "operating system fronts". Existing general-purpose systems such as Linux are the subject of investigation.

This research proposal investigates the predictability of task migration in multi-core real-time systems. Therefore, we propose , a migration- aware real-time executive where migration decisions are no longer based on generic performance parameters but systematically deduced on application-specific knowledge of the real-time tasks. These so-called migration hints relate to temporal and spatial aspects of real-time tasks; they mark potential migration points in their non- sequential (multi-threaded) machine programs. Migration hints enable the operating system to reach decisions that have the most favorable impact on the overall predictability and system performance. The proposal assumes that application-specific hints on admissible and particularly favorable program points for migration represent a cost- effective way to leverage multi-core platforms with existing real-time systems and scheduling techniques. The object of investigation is multi-core platforms with heterogeneous memory architectures. The focus is on the worst-case overhead caused by migration in such systems, mainly depending on the current size and location of the real-time tasks' resident core-local data. This data set, which varies in size over execution time, is determined using tool-based static analysis techniques that derive usable migration hints at design time. In addition, the proposal develops migration-aware variants of standard real-time operating systems, which provide specialized interfaces and mechanisms to utilize these migration hints as favorable migration points at runtime to provide predictable migrations and optimize the overall schedulability and performance of the system.

Within the wide subject of resilience in networked worlds ResPECT focuses on a core element of all networked systems: sensor- and actuator-nodes in cyber-physical systems. Communication up to today is understood and implemented as an auxiliary functionality of embedded systems. The system itself is disruption-tolerant and able to handle power failures or in a limited scope even hardware problems, but the communication isn't part of the overall design. In the best case it can make use of the underlying system resilience. ResPECT develops a holistic operating system and communication protocol stack, assuming that conveying information (the receipt of control data for actuators or the sending of sensor data) is a core task of all networked components. Consequently it must become a part of the operating system's management functionality. ResPECT builds on two pillars: Non-volatile memory and transactional operation. Non- volatile memory in recent years has evolved towards a serious element of the storage hierarchy. Even embedded platforms with exclusively non-volatile memory become conceivable. Network communication, other than social communication, is transactional in its design: Data is collected and under channel constraints like latency, error-resilience and energy consumption and content constraints like age and therewith value of information is transmitted between the communication partners. Other than for operating systems this communication, however, faces many external disruptions and impacts. In addition, the duration of a disruption can have severe implications on the validity of already completed transactions like the persistence of the physical connection. Hence on resumption all this has to be considered. ResPECT consequently will - by interdisciplinary research of operating system and communication experts - develop a model based on transactions and will apply non-volatile memory to ensure, that states during the flow of transactions are known at any point in time and can and will be stored persistently. This monitoring and storing functionality must be very efficient (with respect to the energy consumption as well as to the amount of data to be stored in non-volatile memory) and hence be implemented as a core functionality of the operating system. To ensure generalizability and to have the model available for a variety of future platforms, ResPECT will focus on IP-networks and use communication networks which typically are operated as WAN, LAN or PAN (wide, local or personal area networks).