Commercial Real-time Operating Systems An Introduction. Swaminathan Sivasubramanian Dependable Computing & Networking Laboratory

Size: px

Start display at page:

Download "Commercial Real-time Operating Systems An Introduction. Swaminathan Sivasubramanian Dependable Computing & Networking Laboratory"

Marilyn Golden
5 years ago
Views:

1 Commercial Real-time Operating Systems An Introduction Swaminathan Sivasubramanian Dependable Computing & Networking Laboratory

2 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 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 sharedmemory 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.

6/17/2011. Real-time Operating Systems

6/17/2011. Real-time Operating Systems 1 1 Real-time Operating Systems 2 2 Real-time Operating Systems 3 3 What is an RTOS Provides efficient mechanisms and services for real-time scheduling and resource management Must keep its own time and