
Manycore Operating Systems for Safety-Critical Systems Der Fakult¨atf¨urAngewandte Informatik der Universit¨atAugsburg zur Erlangung der Lehrbef¨ahigungim Lehrgebiet Informatik vorgelegte Habilitationsschrift von Dr. rer. nat. Florian Kluge geboren am 19. August 1979 in Donauw¨orth Januar 2016 Abstract Technological advancements enable to integrate more and more processing cores on single chips. After several years of multicore processors, in the last years the first manycore pro- cessors with 64 and more cores have reached the markets. Concurrently, designers of safety- critical systems strive to integrate more and more powerful software in their systems. For example, advanced driver assistence system increase travelling comfort, but can also improve car safety. Manycore processors can deliver the performance needed by such applications. Due to special requirements in safety-critical systems, a direct use of these processors is mostly hindered. To make them usable in safety-critical domains, existing concepts for software de- sign need to be rethought and new concepts need to be developed. The operating system plays a key role in this process, as it provides the \glue" between application software and hardware platform. This work investigates, how future operating systems for manycore processors should be designed such that they can be deployed in safety-critical systems. A manycore operating system for safety-critical applications (MOSSCA) is designed and applied to several use-cases. Operating system functionalities of MOSSCA are distributed over the cores of a manycore processor as far as possible. MOSSCA provides means to develop applications accordingly. Also it provides the platform for further investigations of operating system mechanisms. One of these is a timing analysis of the boot process in a manycore processor. Further considerations on shared resources show that the timing behaviour of applications is often abstracted too far in scheduling models, thus prohibiting optimisations or the exploitation of existing tolerances. A generic timing model (GTM) is developed to capture timing properties and requirements in cyber-physical system (CPS) during their development. One outcome of GTM are history-cognisant utility functions that can be applied for scheduling. In this work, their ability to map the constraints of (m; k)-firm real-time tasks is examined more closely. Beyond these, a number of further aspects is still being investigated, for example the coordination between tasks in a manycore processor and the further exploitation of GTM. These, and issues still open, are discussed at the end of this work. iii Acknowledgements This work would not have been possible without the support of many people. First of all, I am grateful to Prof. Dr. Theo Ungerer for letting me be part of research group and giving me the opportunity to conduct this work. His friendly manner and mentorship gave me good guidance during the course of this work. I am also grateful to Prof. Dr. Uwe Brinkschulte and Prof. Dr.-Ing. Rudi Knorr for being mentors for this habilitation project and their encouraging comments. I want to thank my former and current colleagues for good cooperations and fruitful discussion, and also for the good times we spent outside work. Some foundations for this work were laid during my stay in Toulouse in autumn 2012. I am greatly indebted to Prof. Dr. Theo Ungerer for making this stay possible, and to Prof. Dr. Christine Rochange, Prof. Dr. Pascal Sainrat, and Beno^ıtTriquet for their friendly reception and the fruitful discussions we had (not only) during this time. I am also thankful to the students who contributed to this work through their bachelor or master theses, or their projects. I am most grateful to my family, especially my parents Hildegard and Erich, for enabling me go to path, and their ongoing support and encouragement. Last but not least, I want to thank my friends for being constant companions and for the good times we have been spending. v Contents Contents vii List of Figures xiii List of Tables xv List of Algorithms xvii I. Baseline 1 1. Introduction 3 1.1. Motivation . .3 1.2. Aims . .5 1.3. Overview . .5 2. Safety-Critical Systems 7 2.1. Definition and Realisation . .7 2.2. Computers and Software in Safety-Critical Systems . .8 2.3. Operating System Requirements . 10 3. Manycore Processors 11 3.1. State of the Art . 11 3.2. Architecture Characteristics . 12 3.3. Manycore Processors and Safety-Critical Systems . 13 3.4. Operating System Requirements . 14 4. State of the Art in Manycore Operating Systems 15 4.1. Existing Approaches . 15 4.1.1. Corey . 15 4.1.2. Barrelfish . 16 4.1.3. Factored operating system . 18 vii CONTENTS 4.1.4. Tessellation . 21 4.1.5. Helios . 23 4.1.6. Osprey . 25 4.2. Virtualisation for Real-Time Systems . 27 4.3. Conclusions . 28 II. An Operating System and Selected Aspects 29 5. The MOSSCA Approach 31 5.1. Assumed Hardware Architecture . 31 5.2. MOSSCA Abstractions . 33 5.2.1. Nodes . 34 5.2.2. Communication Channels . 34 5.2.3. Servers . 34 5.2.4. Interface . 35 5.3. MOSSCA System Architecture . 35 5.3.1. Kernel . 36 5.3.2. Servers . 36 5.3.3. Stub Interfaces . 37 5.3.4. Generality of Approach . 37 5.4. Reference Implementation . 37 5.4.1. Basic Principles . 38 5.4.2. Kernel . 39 5.4.3. OS Server . 40 5.4.4. I/O Server . 40 5.4.5. Inter-Partition Communication Server . 41 5.4.6. Bootrom Server . 41 5.4.7. Construction of a MOSSCA System . 42 5.5. Use-Case Implementations . 42 5.5.1. AUTOSAR OS on a Manycore Processor . 42 5.5.2. System Software in the parMERASA Project . 46 5.5.3. MOSSCA on the T-CREST Manycore Platform . 47 5.6. Fulfilment of Requirements . 49 5.7. MOSSCA and Virtualisation . 50 5.8. Analysis of a MOSSCA System . 50 5.8.1. Bootstrapping . 51 5.8.2. Scheduling of Server Requests . 52 5.8.3. Single-Task Nodes . 52 5.8.4. Local Multitasking . 52 5.8.5. Coordination . 53 5.8.6. Error and Shutdown . 53 5.8.7. Timing Behaviour . 53 5.9. Summary . 53 viii CONTENTS 6. Predictable Boot Process 55 6.1. Bootstrapping . 56 6.1.1. Preliminaries . 56 6.1.2. Baseline: Full Image . 56 6.1.3. Optimisation 1: Splitting Images . 56 6.1.4. Optimisation 2: Self-Distributing Kernel . 57 6.2. Evaluation . 57 6.2.1. Methodology . 57 6.2.2. mwsim .................................... 57 6.2.3. Scenario . 61 6.2.4. Correctness . 65 6.3. Results . 66 6.4. Potentials for Further Work . 69 6.4.1. DMA Units . 69 6.4.2. Use of Best-Effort network-on-chip (NoC) . 69 6.4.3. Online Reconfiguration . 70 6.4.4. General Timing Analysis . 70 6.5. Summary . 70 7. Modeling Timing Parameters of Cyber-Physical Systems 73 7.1. Capturing \Time" During System Design . 74 7.2. Cyber-Physical System Model . 75 7.2.1. System Model . 75 7.2.2. Timing Properties . 76 7.2.3. Timing Requirements . 76 7.3. The Generic Timing Model . 77 7.3.1. Basics . 77 7.3.2. Reactions and their properties . 78 7.3.3. Component Properties . 81 7.3.4. System Requirements . 82 7.4. Periodic and Pseudoperiodic Behaviour . 83 7.5. Summary . 85 8. Task Sets with Relaxed Real-Time Constraints 87 8.1. Related Work . 88 8.1.1. (m; k)-Firm Real-Time Tasks . 88 8.1.2. TUF-Based Real-Time Scheduling . 89 8.2. Scheduling of (m; k)-firm Real-Time Tasks . 90 8.2.1. DBP Scheduling . 90 8.2.2. Fixed (m; k)-Patterns . 91.
Details
-
File Typepdf
-
Upload Time-
-
Content LanguagesEnglish
-
Upload UserAnonymous/Not logged-in
-
File Pages184 Page
-
File Size-