1 / 29

Commercial Real-time Operating Systems – An Introduction

Commercial Real-time Operating Systems – An Introduction. Swaminathan Sivasubramanian Dependable Computing & Networking Laboratory swamis@iastate.edu. outline. Outline. Introduction RTOS Issues and functionalities LynxOS QNX/Neutrino VRTX VxWorks Spring Kernel Distributed RTOS ARTS

Jimmy
Download Presentation

Commercial Real-time Operating Systems – An Introduction

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Commercial Real-time Operating Systems – An Introduction Swaminathan Sivasubramanian Dependable Computing & Networking Laboratory swamis@iastate.edu

  2. outline Outline • Introduction • RTOS Issues and functionalities • LynxOS • QNX/Neutrino • VRTX • VxWorks • Spring Kernel • Distributed RTOS • ARTS • MARS

  3. Commercial and Research RTOS • Commercial RTOSes different from traditional OS – gives more predictability • Used in the following areas such as: • Embedded Systems or Industrial Control Systems • Parallel and Distributed Systems • E.g. LynxOS, VxWorks, pSoS, Spring,ARTS, Maruti, MARS • Traditionally these systems can be classified into a Uniprocessor, Multiprocessor or Distributed Real-Time OS

  4. RTOS – Issues • Real-Time POSIX API standard compliance • Whether pre-emptive fixed-priority scheduling is supported • Support for standard synchronization primitives • Support for light weight real-time threads • APIs used for task-handling • Scalability • Footprint of the kernel – how huge is the kernel? • Can the kernel be scaled down to fit in the ROM of the system?

  5. RTOS – Issues (contd..) • Modularity • How does the functionalities like I/O, file system, networking services behave? • Can they be added at run-time or can they be changed at run-time? • Can a new service be added at run-time? • Type of RTOS kernel • Monolithic kernel – less run-time overhead but not extensible • Microkernel – high run-time overhead but highly extensible

  6. RTOS – Issues (contd..) • Speed and Efficiency • Run-time overhead – most of the modern RTOSes are microkernels, but unlike traditional RTOSes they’ve less overhead • Run-time overhead is decreased by reducing the unnecessary context switch • Important timings such as context switch time, interrupt latency, semaphore latency must be minimum • System Calls • Non preemptable portions of kernel functions necessary for mutual exclusion are highly optimized and made short and deterministic

  7. RTOS – Issues (contd..) • Interrupt Handling • Non preemptable portions of the interrupt handler routines are kept small and deterministic • Interrupt handlers are scheduled and executed at appropriate priority • Scheduling • Type of scheduling supported – RMS or EDF • Number of priority levels supported – 32 to be RT-POSIX compliant; many offer between 128-256 • Type of scheduling for equal priority threads – FIFO or Round-Robin • Can thread priorities be changed at run-time?

  8. RTOS – Issues (contd..) • Priority Inversion Control • Does it support Priority Inheritance or Ceiling protocols for scheduling? • Memory Management • Can provide virtual-to-physical address mapping • Traditionally does not do paging • Networking • Type of networking supported – deterministic network stack or not

  9. Lynx OS • Microkernel design • Means the kernel footprint is small • Only 28 kilobytes in size • The small kernel provides essential services in scheduling, interrupt dispatching and synchronization • The other services are provided by kernel lightweight service modules, called Kernel Plug-Ins (KPIs) • New KPIs can be added to the microkernel and can be configured to support I/O, file systems, TCP/IP, streams and sockets • Can function as a multipurpose UNIX OS

  10. Lynx OS (contd..) • Here KPIs are multi-threaded, which means each KPI can create as many thread as it want • There is no context switch when sending a message to a KPI • For example, when a RFS (Request for Service) message is sent to a File System KPI, this does not request a context switch • Hence run-time overhead is minimum • Further, inter KPI communication incurs minimal overhead with it consuming only very few instructions • Lynx OS is a self hosted system – wherein development can be done in the same sytem

  11. Lynx OS (contd..) • In such a system, there is a need for protecting the OS from such huge memory consuming applications (compilers, debuggers) • LynxOS offers memory protection through hardware MMUs • Applications make I/O requests to I/O system through system calls • Kernel directs I/O request to the device driver • Each device driver has an interrupt handler and kernel thread

  12. Lynx OS (contd..) • The interrupt handler carries the first step of interrupt handling • If it does not complete the processing, it sets an asynchronous trap to the kernel • Later, when kernel can respond to the software interrupt, it schedules an instance of the kernel thread to complete the interrupt processing

  13. QNX/ Neutrino • SMP RTOS – requires high end, networked SMP machines with GBs of physical memory • Microkernel design – kernel provides essential threads and real-time services • Other services are considered as resource managers and can be added or removed at run-time • The footprint of microkernel is 12kb.

  14. QNX/ Neutrino (contd..) • QNX is a message passing operating system • Messages are basic means of interprocess communication among all threads • Follows a message based priority tracking feature • Messages are delivered at the priority order and the service provider executes at the priority of the highest priority clients waiting for service • So, if the highest priority task wants to do read some data from file, the file system resource manager will execute at this task’s priority

  15. QNX/ Neutrino (contd..) • When a service provider thread wants to provide service, then it creates a channel (for exchanging messages) with its service identifier for identification • To get a service from a provider, the client thread attaches it to the provider’s channel • Within the client, this connection is directly mapped to the file descriptor (so RFS can be sent directly to the file descriptor) • QNX messages are blocking unlike POSIX message standards

  16. VRTX • VRTX has two multitasking kernels • VRTXsa • designed for performance • Provides priority inheritance, POSIX compliant libraries • Supports multiprocessing • System calls fully preemptable and deterministic • VRTXmc • designed for low power consumption • Used for cellular phones and hand-held devices • Rather than providing optional components provides hooks for extensibility – application can add its own system calls

  17. VxWorks • Monolithic Kernel • Leads to an improved performance with less run-time overhead • However the scalability is poor I.e. the footprint of the kernel is affected a little. • Provides interfaces specified by RT-POSIX standards in addition to its own APIs • Though not a multiprocessor OS, provides shared-memory objects: shared binary and counting semaphores • It has the standard MMU as a modern OS • Provides basic virtual-to-physical memory mapping • Allows to add new mappings and make portions of memory non cacheable

  18. VxWorks (contd..) • When memory boards are added dynamically, to increase the address space for interprocess communication • The data is made non cacheable, to ensure cache consistency • Reduced Context Switch time • Saves only those register windows that are actually in use (on a Sparc) • When a task’s context is restored, only the relevant register window is restored • To increase response time, it saves the register windows in a register cache – useful for recurring tasks

  19. Spring Kernel • Goal – development of dynamic, distributed real-time system • System is a network of multiprocessors, each multiprocessor containing one or more processors, I/O subsystems • I/O subsystem is a separate entity from Spring kernel, handling non-critical I/O, slow I/O devices and fast sensors • Design Principle – Segmentation & Reflection

  20. Spring Kernel (contd..) • Segmentation • dividing resources of the systems into units • Size of unit depends on application requirements • Helps in determining the resource constraints of online scheduling algorithms • Reflection • Concept of reasoning its own state and its environments • Required for handling situations in highly dynamic environments (where handcrafting is infeasible)

  21. Spring Kernel (contd..) • Scheduling – consists of 4 modules • Process-resident dispatcher – simply removes the task from Global System Task Table (GSTT) • Local Scheduler (per processor) – responsible for locally guaranteeing that a new task can make its deadline and for ordering processor specific tasks in STT • Global Scheduler – finds a site for execution for any task that cannot be locally guaranteed • Meta Level Controller – can adapt various parameters by noticing significant changes

  22. Spring Kernel (contd..) • Memory Management • OS is core-resident • No dynamic memory allocation to eliminate large and unpredictable delays (due to page faults and page replacements) • Kernel pre-allocates a fixed number of instances of the some of kernel data structures • Tasks are accepted dynamically if the necessary data structures are available • Inter-Process Communication • Mailboxes and communication primitives are used for communication • No need for semaphores since mutual exclusion is taken care in scheduling

  23. ARTS - Distributed OS • Distributed real-time OS – provides a predictable distributed real-time computing environment • Distributed computing environment • Heterogeneous computing environment • Need for global view of the system and resources • No over-utilization and under-utilization of a particular system in a distributed system • Guaranteeing predictability in such a system is difficult than in multiprocessor system case

  24. ARTS (Contd..) • How to synchronize the clocks in a distributed system? • Scheduling • Integrated time-driven scheduler • ITDS scheduler provides an interface between the scheduling policies and the rest of the operating system • Allows different scheduling policies to exist (though only one can be used at a time) • Communication scheduling • Extended RMS for communication scheduling – integrating message and processor scheduling

  25. MARS – Distributed RTOS • Maintainable Real-Time System (MARS) –focuses on fault tolerance in distributed RTOS • Objective • To provide guaranteed timely response under peak load conditions • To support real-time testability by breaking up the system into subsystem • Time Driven System – system initiates activities at pre-determined times • Better performance than event driven systems • Control signals are based on the physical time, hence in presence of a global physical time – no need for control signals across subsystem interfaces

  26. MARS (Contd..) • System Architecture • MARS application consists of a set of clusters (autonomous subsystems), several components of a cluster connected by a real-time bus • Each component runs an identical copy of the operating system • Different clusters are connected through an inter-cluster interface, forming a network • Cluster consists of Fault-Tolerant Units (FTUs) consisting of replicated components providing redundancy • Shadow components update their own internal state and monitor the operation of active components • Shadow becomes active, when active fails • Each message is also sent twice on real-time bus

  27. MARS (Contd..) • Fault Tolerance • Addresses both transient and permanent faults • Messages have checksums and h/w comp. are self-checking • Uses robust storage structures • Application software detects errors by executing each task twice (catching transient faults) • MARS is fail silent – component is turned on detecting first error to avoid fault propagation • Upon detection – shadow component takes over the final one

  28. MARS (Contd..) • Tasks and messages • Tasks (periodic and aperiodic) are scheduled by static scheduling schemes • Hard real-time tasks are run at specific intervals that are known during system initialization • Soft real-time tasks are run at intervals not used by hard real-time tasks • Communication through message passing – also uses state messages (produced periodically at predetermined times), conveying state of the system • To avoid unpredictable delays in CSMA/CD protocols, MARS uses a TDMA protocol to provide collision-free access to Ethernet (atmost one hard RT message for each slot – remaining for soft RT messages)

  29. MARS (Contd..) • MARS uses only one kind of interrupts – periodic clock interrupt. • Interaction with peripherals is through polling • Scheduling • Scheduling done offline • Assumes that the running task will yield the CPU at the end of its quantum • Task switching is done by major handler every 8 milliseconds • Change can be triggered by invoking a system call or receiving an appropriate message.

More Related