Levels of Specialization in Real-Time Operating Systems

Levels of Specialization in Real-Time Operating Systems

Levels of Specialization in Real-Time Operating Systems Björn Fiedler, Gerion Entrup, Christian Dietrich, Daniel Lohmann Leibniz Universität Hannover {fiedler, entrup, dietrich, lohmann}@sra.uni-hannover.de Abstract—System software, such as the RTOS, provides no robustness, security and so on; it increases the safety margins or business value on its own. Its utility and sole purpose is to serve makes it possible to cut per-unit-costs by switching to a cheaper an application by fulfilling the software’s functional and nonfunc- hardware. For price-sensitive domains of mass production, such tional requirements as efficiently as possible on the employed as automotive, this is of high importance [8]. hardware. As a consequence, every RTOS today provides some means of (static) specialization and tailoring, which also has a Intuitively, any kind of specialization requires knowledge long tradition in the general field of system software. about the actual application: The more we know, the better However, the achievable depth of specialization, the resulting we can specialize. In the domain of real-time systems (RTSs), benefits, but also the complexity to reach them differ a lot we typically know a lot about our application and its exe- among systems. In the paper, we provide and discuss a taxonomy cution semantics on the employed RTOS: To achieve real- for (increasing) levels of specialization as offered by (real-time) time properties, all resources need to be bounded and are system software today and in the future. We argue that system software should be specialized as far as possible – which is scheduled deterministically. Timing analysis depends on the always more than you think – but also discuss the obstacles that exact specification of inputs and outputs, including their inter- hinder specialization in practice. Our key point is that a deeper arrival times and deadlines; schedulability analysis requires that specialization can provide significant benefits, but requires full all inter-task dependencies are known in advance – and so on. automation to be viable in practice. Even though all this knowledge should pave the road to a very rigorous subsetting of the RTOS functionality, this rarely I. INTRODUCTION happens in practice. Part of the problem is that the specialization of the RTOS typically has to be performed manually by the While the domain of real-time control systems is broad and application developer or integrator, which adds significant diverse with respect to both, applications and hardware, each complexity to the overall system development and maintenance concrete system has typically to serve a very specific purpose. process. We are convinced that automation is the key here, as This demands specialization of the underlying system software, most of the required knowledge could be extracted by tools the real-time operating system (RTOS) in particular: An “ideal” from the application’s code and design documents – the RTOS system software fulfills exactly the application’s needs, but no specialization should become an inherent part of the compilation more [19]. Hence, most system software provides built-in static process, like many other optimizations. variability: It supports a broad range of application requirements and hardware platforms, but can be specialized at compile-time Another part of the problem is, however, that static spe- with respect to a specific use case. Historically, this has led to cialization itself is only rarely understood. This holds in our the notion of system software as program families [25], [14] observation for both, RTOS users and RTOS designers, both as well as a myriad of papers from the systems community of which typically have been educated (and tend to be caught) that demonstrate the efficiency gains by specializing kernel in the mindset and APIs of general-purpose operating systems, abstractions to the employed application, hardware, or both. such as Linux or Windows. So while every system software Examples include [27], [6], [20], [26]. provides some means for static specialization and tailoring, the rigorosity at which this (a) could be possible in principle, (b) is A. System Software Specialization possible in the actual RTOS provisioning, and (c) is employable by users in practice, differs a lot. Specialization (of infrastructure software) for a particular application–hardware setting is a process that aims to improve B. About This Paper on nonfunctional properties of the resulting system while leaving the application’s specified functional properties intact. Our goal with this paper is to shed some light on the If the application employs an RTOS with a specified API and aspects and the fundamental levels of specialization that semantics (e.g., POSIX [2], OSEK/AUTOSAR [4], ARINC are provided by system software today and, maybe, in the [3]), a specialized derivative of the RTOS does no longer fulfill future. We claim the following contributions: (1) We provide a this API and semantics in general, but only the subset used classification for specialization capabilities on three increasing by this concrete application and hardware. If successful, this levels (Section II). (2) We discuss the challenges and benefits specialization leads to efficiency gains with respect to memory of system specialization by examples from the literature footprint, hardware utilization, jitter, worst-case latencies, (Section III). (3) We show, on the example of a small experiment with FreeRTOS [5], the potential of different specialization This work was partly supported by the German Research Foundation (DFG) levels, even for an RTOS API that is supposed to “look like under grant no. LO 1719/4-1 POSIX” (Section IV). (g) Generic (a) Abstractions (b) Instances (c) Interactions activate activate activate activate Thread interrupt ISR Thread interrupt ISR Thread activate ISR T T ... I I ... T T ... I I ... activate activate block block preempt interrupt preempt wait preempt wait Thread interrupt ISR T1 activate I1 set Event set set Event set T1 T2 I1 block T2 E E ... interrupt E E ... interrupt preempt interrupt T2 I1 T1 «instanceOf» Thread Thread T1 : Thread interrupt X «instanceOf» activate ISR ISR T2 : Thread X «instanceOf» interrupt Nested ISR Nested ISR I1 : ISR iret Features Features Event Event resume RTOS API/standard, like POSIX [2], Like Linux or eCos [22], specialized Like ERIKA [1], specialized for an Like dOSEK [10], specialized for the OSEK/AUTOSAR [24], or ARINC [3]. for applications that employ threads application that employs well-defined concrete interactions that happen in a Supports any application. and ISRs, but not events. threads T1 and T2 and ISRs I1. specific application. Supports a class of applications. Supports a specific application. Supports a concrete implementation. Fig. 1: Levels of RTOS specialization. From left to right, each level further constraints how the application may use the kernel. Many aspects about specialization we describe in this paper more system components of an already existing implementation. are based on our own experience with the design, development, For real-time systems, it can take place in the application A, and employment of highly configurable application-tailorable the RTOS, or/and the hardware HW. For the rest of the paper, system software. We apologize for the (shameless) number of we focus on the specialization of the RTOS, while application self-citations, but felt that leaving them off would not have and hardware remain unchanged. contributed to the accessibility of the paper. The specialized RTOS0 fulfills all requirements of the specific application that runs on top and works on the specified II. A TAXONOMY OF SPECIALIZATION LEVELS hardware. However, this RTOS0 does not necessarily provide 0 In this section, we give a taxonomy of system specialization the correct semantics to execute an alternative A or correct and the different levels specialization can reach. In short, a instructions to execute on an alternative HW0. Therefore, RTOS generic RTOS (g) can be specialized by (a) removing complete specialization always depends on the application that uses the abstractions (e.g., threads or a specific syscall), (b) make RTOS and the targeted hardware. instances fixed (e.g., there are only threads T1 and T2), and In the following we exemplify this by a simple RTOS that (c) make interactions fixed (e.g., only T1 waits on event E1). supports only three abstractions: Threads, interrupt service We examine these terms at the example of RTSs, which we routines (ISRs) and Events. Figure 1 (g) shows the whole range specify for the purpose for this paper as follows: of functions provided by our example RTOS as an interaction A (hard) real-time system RTS consumes time-labeled input graph. Nodes are system abstractions that are provided by events ~I and produces observable, time-labeled output events the RTOS standard; edges are interactions between them. The O~ , while fulfilling strict timing constraints between both event generic RTOS (i.e., the respective standard) provides the illusion A RTOS that abstractions can be instantiated arbitrarily often and all streams. An implementation RTS HW of the abstract RTS consists of a concrete application A that runs, mediated by a concrete instances (nodes within nodes) can interact according to their RTOS implementation RTOS, on a concrete hardware HW. We abstraction. For example, every ISR can activate every thread. encapsulate the specification and timing requirements of the When we specialize our generic RTOS, we (a) remove RTS RTS in an equality operator = that compares two outputs. abstractions, (b) make instances fixed, and (c) forbid concrete interactions. The shrunk interaction graph reflects the reduced RTS A ~ ~ RTOS ~ flexibility of the specialized RTOS. We define three levels of RTS(I) = O = RTS HW (I) specialization, which subsequently need more information about the actual interaction graph of the application and remove more Every correct implementation of RTS produces an output flexibility. Every level is a true superset of the previous one. stream that is equal, under the RTS specification, to the outputs of the abstract/ideal RTS.

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    6 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us