Commercial real time operating systems an introduction
1 / 29

Commercial Real-time Operating Systems - PowerPoint PPT Presentation

  • Updated On :

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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Commercial Real-time Operating Systems ' - Jimmy

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Commercial real time operating systems an introduction l.jpg

Commercial Real-time Operating Systems – An Introduction

Swaminathan Sivasubramanian

Dependable Computing & Networking Laboratory

[email protected]

Outline l.jpg



  • Introduction

  • RTOS Issues and functionalities

  • LynxOS

  • QNX/Neutrino

  • VRTX

  • VxWorks

  • Spring Kernel

  • Distributed RTOS

    • ARTS

    • MARS

Commercial and research rtos l.jpg
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

Rtos issues l.jpg
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?

Rtos issues contd l.jpg
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

Rtos issues contd6 l.jpg
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

Rtos issues contd7 l.jpg
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?

Rtos issues contd8 l.jpg
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

Lynx os l.jpg
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

Lynx os contd l.jpg
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

Lynx os contd11 l.jpg
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

Lynx os contd12 l.jpg
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

Qnx neutrino l.jpg
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.

Qnx neutrino contd l.jpg
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

Qnx neutrino contd15 l.jpg
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

Slide16 l.jpg

  • 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

Vxworks l.jpg

  • 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

Vxworks contd l.jpg
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

  • Spring kernel l.jpg
    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

    Spring kernel contd l.jpg
    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)

    Spring kernel contd21 l.jpg
    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

    Spring kernel contd22 l.jpg
    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

    Arts distributed os l.jpg
    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

    Arts contd l.jpg
    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

  • Mars distributed rtos l.jpg
    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

    Mars contd l.jpg
    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

    Mars contd27 l.jpg
    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

    Mars contd28 l.jpg
    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)

    Mars contd29 l.jpg
    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.