21 Real-Time Operating Systems

21 Real-Time Operating Systems This section is devoted to real-time operating systems (RTOS) for supporting applications with real-time requirements. In these applications, most real-time requirements are derived form the physics of the environment that is being controlled or monitored and this implies that most real-time systems are embedded computer systems, and that an RTOS has to provide facilities for supporting embedded applications. There are many commercial products that can be categorized as an RTOS, even though there is a wide range of products, from very small real-time kernels for small embedded applications with a memory footprint in the few kilobytes range, to the large multipur- pose systems controlling a very complex real-time system. Despite this broad range of systems, an RTOS always has the property of being able to provide the required level of service with bounded response times. In the past and even today, many real-time applications were built without an operating system. They were usually simple applications with a simple cyclic scheduler and some interrupt driven routines, and with all the I/O drivers written directly by the application developer. However, with the cost and power of computers today, real- time applications are much more complex, and require full concurrency support, advanced scheduling services, networking, advanced memory management, time management, and in some cases even graphical user interfaces and file systems for secon- dary storage. These are the services typically provided by operating systems, and this has made their use more important in real-time systems. It is expected that this ten- dency will continue in the future. In this section we will present a cross section of the most important commercial RTOS’s available today, and we will also discuss the standards that play a major role in operating systems for real-time embedded applications. Some of these standards are recognized by international bodies, while others are industry standards. In both cases, they belong to a community of users and developers, and not to individual companies. The role of standards in operating systems in general is very important as it provides portability of applications from one platform to another. With the constant evo- lution of hardware it is very important to be able to port an application that was developed for a particular platform into new hardware platforms. The programmers are also easily transferred between platforms because the standard imposes a particular model of the system’s application program interface. In addition, standards open the door to the possibility of having several OS providers for a single application or com- pany, which promotes competition among vendors and increases quality and value. There are few real-time operating system standards that specify or facilitate portability at the binary code level. The reason is that in real-time systems there are many kinds of processor architectures, from very small embedded systems to very large processors handling large amounts of data. Binary code portability is usually only practical for families of processors with the same programming architecture. There- fore, current operating system standards mostly specify portability at the source code Artist FP5 Consortium: Embedded Systems Design, LNCS 3436, 258 – 286, 2005. © Springer-Verlag Berlin Heidelberg 2005 21.1 Landscape 259 level, requiring the application developer to recompile the application for every different platform. Portability in real-time systems is not complete with current technology. The interface between the software and the hardware devices, mostly encapsulated inside the device drivers, is usually non-portable. And in embedded real-time systems it is usual to access special hardware that requires custom-developed drivers. In many systems this can be a significant part of the overall software development. Still, the majority of the application is usually outside the device drivers and can be made portable if developed to comply to one of the standards. Another source of non portability is that in real-time systems the port from one platform to another does not imply that the timing behaviour will be unaffected; timing requirements may or may not be met in the new platform (even if it is a faster platform) and the real-time analysis must be reevaluated as part of the migration proc- ess. An evaluation of the timing behaviour of the new platform can be done before the migration, to minimize the risk. In this section, after presenting a landscape of existing RTOS and operating system standards, we discuss their limitations and illustrate the new trends in this area. 21.1 Landscape Although there are a large variety of real-time operating systems varying in sizes, level of provided services, and efficiency, there are some common elements that can be found in most of them [BG-EC] [BG-DS] [FAQ], giving an answer to: what makes an OS real-time? • An RTOS usually provides support for concurrent programming via processes or threads or both. Processes usually provide protection through separate address spaces, while threads can cooperate more easily by sharing the same address space, but with no protection. • Real-time scheduling services are provided because this is one of the keys to ob- taining a predictable timing behaviour. Most current RTOS’s provide the notion of a scheduling priority, usually fixed, as for the moment there are few systems providing deadline-driven or other dynamic-priority scheduling. • Although some RTOS’s designed for high-integrity applications use non preemp- tive scheduling, most support preemption because it leads to smaller latencies and a higher degree of utilization of the resources. • The OS has to support predictable synchronization mechanisms, both for events or signal and wait services, as well as for mutual exclusion. In the later case some way of preventing priority inversion is required because otherwise very improb- able but also very long delays may occur. The common mechanism used to pre- vent priority inversion is the use of some priority inheritance protocol in the mutual exclusion synchronization services. Priority inversions must also be avoided in the internal kernel implementation; among other things this requires the use of priority queues instead of regular FIFO queues in those OS services where processes or threads may be queued waiting for some resource. • The OS has to provide time management services with sufficient precision and resolution to make it possible for the application to meet its timing requirements. 260 21 Real-Time Operating Systems • OS behaviour should be predictable, and so metrics of the response time bounds of the services that are used in real-time loops should be clearly given by the RTOS manufacturer or obtained by the application developer. These metrics include the interrupt latency (i.e., time from interrupt to task run), the worst case execution time of the system calls used in real-time loops, and the maximum time during which interrupts are masked or disabled by the OS and by any driver. The real-time operating systems presented in this section largely fit into this charac- terization. An RTOS is generally chosen not only for its real-time characteristics, but also for the middleware that is integrated in the RTOS, such as file system, communication stack, for its portability to different platforms (i.e., the board support packages that are provided), and for the associated cross-development environment. A commercial RTOS is usually marketed as the run-time component of an embedded development platform, which also includes a comprehensive suite of (cross-) development tools and utilities and a range of communications options for the target connection to the host, in an Integrated Development Environment (IDE). Moreover, the vendor generally provides development support. For each successful open source RTOS there is also at least one commercial distributor that provides development tools and development support. For many embedded-systems companies, the availability of development tools and support is a major requirement for choosing a particular RTOS. The quality of the overall package deal, including service and pricing strategy is often decisive in choosing a particular RTOS. Not all operating systems presented in this landscape satisfy the RTOS criteria given above and/or the RTOS definition in the Introduction. To get a clearer view of the landscape, we distinguish a number of subclasses. We first present the landscape on the operating system standards, then some major commercially available RTOS, then some LINUX variants, some other open source RTOS, and finally, some typically embedded operating systems that are not real-time. Before going into the detailed descriptions of the RTOS, the development and timing analysis tools will be addressed first. Tools In this section, a general description is given of the development tools that make up the Integrated Development Environment (IDE), and of timing-analysis tools that, in some cases, are included in or can be attached to the IDE. Development Tools In addition to the general programming tools, such as (graphical) editors, compilers, source code browsers, high-level debuggers, and version control systems there are a number of tools specifically aiming cross development, and run time analysis. Ad- vanced tools in this domain not only address development and analysis of the own application code, but also third-party code and the integration with the OS. Memory analyzers show memory usage and reveal memory leaks before they cause a system failure. Performance profilers reveal code performance bottlenecks and show where a CPU is spending its cycles, providing a detailed function-by-function analysis. Real- 21.1 Landscape 261 time monitors allow the programmer to view any set of variables, while the program is running. Execution tracers display the function calls and function calling parame- ters of a running program, as well as return values and execution time.

Load more