Sei sulla pagina 1di 38

Realtime Operating Systems

Features Difference between RTOS and GPOS Comparison between different OS

What is a Real-time OS?

A RTOS (Real-Time Operating System)

Is an Operating Systems with the necessary features to support a Real-Time System A Good RTOS is one that has a bounded (predictable)
behavior under all system load scenarios. What is a Real-Time System?

A system where correctness depends not only on the


correctness of the logical result of the computation, but also on the result delivery time. A system that responds in a timely, predictable way to unpredictable external stimuli arrivals

RTOS A functional diagram

Application tasks

Hardware
3

Fundamental Requirements of an RTOS

Additional Requirements

RTOS A myth!

RTOS Key Players

Kernel

Features of Real Time Kernels

Task Management. Timer Management. Intertask Communication. Memory Management Dynamic Memory Allocation. Device I/O Supervisor

Tasks & Task Control Basics

10

Task Management & Scheduling

Task management includes the following Task Creation : Task creation should be dynamic; that is task creation should be allowed during run-time.

Task Scheduling : Flexible system will allow task scheduling via events, time
slicing.

Task Priorities : Priority based preemptive scheduling. Priorities must be real time responsive and preferably
dynamic.

11

Tasks States

12

Scheduler

13

Non Preemptive Kernel

14

Non Preemptive Kernel

15

Preemptive Kernel

16

Preemptive Kernel

17

Development Methodology

18

POSIX standards in RTOS

1003.1a - Interface to basic OS functions

1003.1b - Real time extensions 1003.1c - Multiple threads 1003.1h - High availability 1003.13 - Embedded systems having space/resource limitations

19

What requirements are imposed on RTOS?

Timers Periodic timers, delivery using POSIX signals Priority scheduling Fixed preemptive scheduling with at least 32 priority levels Inter-process communication Message passing Shared memory Memory locking functions to prevent swapping of memory pages Multiple scheduling schemes for same priority level: FIFO, RR, others
20

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?
21

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
22

RTOS Issues (contd..)

Speed and Efficiency Run-time overhead most of the modern RTOSs are microkernel, but unlike traditional RTOSs they have runtime 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
23

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 Number of priority levels supported 32 to be RT-POSIX compliant; many offer between 128256 Type of scheduling for equal priority threads FIFO or Round-Robin Can thread priorities be changed at run-time?
24

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
25

Comparison of RTOS & GPOS

RTOS Application code & RTOS are compiled linked together. Application runs first and calls the OS.

GPOS Application code & OS are and separate. The OS runs first & calls the application. OS is a separate entity than process it runs. Multipurpose, General Purpose

RTOS only runs when called by the the application. Dedicated to single embedded application. Few if any extras.

File System, IO system, User Interface. Occasionally hangs.

Designed to run forever without crashing.

26

RTOS Vs. GPOS

27

RTOS Comparison Table


OSE
Priority Schedulin g Preemptive and cyclic

LynxOS
Fixed Priority and Preemptiv e

ITRON
Fixed Priority and Preempt ive

QNX
Fixed Priority and Preemp tive

VRTX
Fixed Priority and Preempti ve

VxWork s
Fixed Priority and Preempt ive

Win-CE
Fixed Priority and Preemptive

Samelevel Schedulin g Synchroni zation Construct s

RR

RR/Quantu m/FCFS

FCFS

RR/Ada ptive

RR

RR

RR(1-7) FCFS(0)

Signals with buffers 1 fast semaphore Bin Semaphore

Semaphor es Conditiona l variables Queues signals

Semaph ores Event flags Mail boxes

Semap Semapho hores, res Messag e passin g Signals

Semaph ores Interrupt locks, preempt ive locks Semaph ores HLP

Critical section Events Mutexes

Synchroni zation protocol

none

PIP

none

PIP

PIP

PIP

28

RTOS Comparison Table Cont..


OSE LynxOS ITRON QNX VRTX VxWork s Win-CE

ISR

Interrupt Processes

Preemptib le Interrupt handlers

Implem Preemp Preempti entation tible ble Specific interrup Interrupt t handlers handler Special s Context

Special context

Interrupt service threads

Signals

Non-POSIX

POSIX

none

POSIX

Queued POSIX

Queued POSIX

Nested Interrupt s

Yes

Yes

Yes

Yes

Yes

Yes

No

29

RTOS Comparison Table Cont..


OSE LynxOS ITRON QNX VRTX VxWork s Win-CE

Communi cation construct s

Signals with buffers, shared memory

Message queues, Pipes, Sockets, Shared Memory

Mail boxes, Data queues

Messag es, pipes, queues, Sockets

Message queues, Pipes, Sockets, Shared memory

Messag e queues, Pipes, Sockets, Shared memory, RPC

Shared Memory

Virtual memory

Segmented

Demand paged Yes

no

Yes

yes

Optional Segmented

Dynamic Pools/blocks Allocation

Fixed pool

Yes

Yes

Yes

yes

30

Comparison of VxWorks,QNX & Embedded Linux

31

Comparison of VxWorks,QNX & Embedded Linux

32

Comparison of VxWorks,QNX & Embedded Linux

33

Comparison of VxWorks,QNX & Embedded Linux

34

Comparison of VxWorks,QNX & Embedded Linux

35

Embedded Linux and Neutrino Embedded Linux


Access to source code Proprietary source not available.
Royalty Free for hard real-time Some real-time add-ons are royalty-based

QNX Neutrino
Customer can gain access to the source.
Hard real-time out of the box

SMP inherent in the kernel, but there are scalability issues. Resource requirements ( Cost of Kernel developers Ownership) required. Accountability for Code Quality Who does the customer turn to? GPL prohibits innovative Licensing that protects Intellectual Property business Multi-Processing Capabilities
Hard Real-time capabilities

Distributed inter-process, inter-node communications No kernel development requirements Access to the kernel architects at QNX QNX licensing protects IP
Inherent

Availability of tools Portability

Highest priority processes can still be blocked + other issues Cited as a major issue with embedded Linux developers Different implementations

Gnu Toolset , Solaris or Windows. Momentics and Eclipse. Full POSIX compliance.

36

VxWorks and Neutrino Wind River VxWorks


APIs

QNX
Full POSIX compliance. Allows OEMs to leverage large UNIX/Linux developer community and minimal port time of the latest software apps.. Microkernel full memory protection using the process model
SMP Built into the Microkernel. Drivers, file systems and applications gain the advantage of SMP without code changes. Any process can run on any CPU. Development can be done on a host (cross development) or directly on the target system (selfhosted). Self-hosted option eliminates timeconsuming process of having to develop one platform and test on another. Built in. Any application can communicate transparently across any number of redundant links, using any combination of network media.

- Proprietary APIs.. Supports POSIX, but


strays from the standard.

Memory Model
MultiProcessing Capabilities

Monolithic kernel vulnerability


Applications and drivers must be modified for
SMP. OS and drivers run on one processor, and hand-tuned SMP applications run on the remaining processor. Traditional embedded development model: Tedious and time-consuming. Now promoting immature Eclipse-based tools.

Developmen t Environment
Redundant networks

As with most other OSs, no built-in support.


Up to the individual software developer to implement support for each link this must be done by hand on an application -by-application basis. Both Zinc and Wind ML are proprietary UI technologies. Neither is a true windowing system, but a graphics library that lacks the functionality to host multiple full-scale applications

GUI Options

Unlike the Zinc and WindML graphics libraries, Photon is a true windowing system that lets multiple applications share screen real estate without interfering with one another. Users can interact with several applications all at once.

37

WinCE and Neutrino Microsoft WinCE.NET


Hard Real-time capabilities Upgradeability Unproven and not considered a hard RTOS No hot swapping or dynamic loader Win 32 Proprietary API

QNX Neutrino
Proven and Perceived

APIs Processor Independence Scalability Fault Resilience Kernel Stability Distributed Computing Development Model High Availability Development Tools

Dynamic upgradeable built in POSIX Compliance Can move drivers without recoding. 1000 of concurrent processes Process error dont effect the kernel Highly consistent from app to app Qnet. Built-in distributed priority inheritance Self hosted or cross development HA - toolkit Eclipse based Momentics on Windows , Unix or Linux. 38

Drivers must be rewritten for other processors Limited to 32 processes No inherent architecture for fault tolerance Varies with system configuration No inherent support Combination of desktop and embedded development model. None Platform Builder, Visual basic and Visual Studio hosted only on Windows.

Potrebbero piacerti anche