Types of Real- Time Operating Systems

jaspersugarlandSoftware and s/w Development

Dec 14, 2013 (3 years and 8 months ago)

98 views





Real Time Operating Systems

Survey Paper I






Author(s):

Amit Sharma, Ali Abbas, Dhaval Sanghvi


Document Version:

1
.0


Document Status:

Open



Document Relea
se Date:

October 5, 2002


Security Classification:

Not confidential






i





ii

Audience

This document is intended for people in academia as well as professionals who are in the
software and research and development domains. Knowledge of some basic concepts in
op
erating systems such as processes, tasks, semaphores, process states and memory
management is assumed.




iii

Intent of this Document

This document is submitted as the first Survey Paper to Dr. Khalil in fall 2002. It is intended to
be a learning guide in the are
a of Real Time Operating Systems (RTOS). It serves as a help guide
for the concepts of RTOS in general and VxWorks in particular.





Survey Paper I

Real Time Operati
ng Systems

1

Table of Contents

REAL TIME OPERATING
SYSTEMS

................................
................................
................................
....................

I

SURVEY PAPER I

................................
................................
................................
................................
.........................

I

AUDIENCE

................................
................................
................................
................................
................................
.
II

INTENT OF THIS DOCUM
ENT

................................
................................
................................
...........................

III

TABLE OF CONTENTS

................................
................................
................................
................................
............

1

GETTING STARTED WITH

REAL TIME OPERATING
SYSTEMS (RTOS)

................................
..................

2

I
NTRO
DUCTION

................................
................................
................................
................................
...........................

2

R
EAL
-
TIME SYSTEMS
&

REAL
-
TIME OPERATING SYSTE
MS

................................
................................
..........................

2

A
PPLICATIONS OF A
RTOS

................................
................................
................................
................................
.........

3

TYPES OF REAL
-

TIME OPERATING SYSTE
MS

................................
................................
..............................

3

H
ARD
R
EAL
-

T
IME

O
PERATING
S
YSTEMS

................................
................................
................................
...................

3

S
OFT
R
EAL
-
T
IME
O
PERATING
S
YSTEMS

................................
................................
................................
.....................

4

RTOS FEATURES

................................
................................
................................
................................
......................

4

M
ULTITASKING

................................
................................
................................
................................
..........................

5

S
YNCHRONIZATION

................................
................................
................................
................................
....................

5

I
NTERR
UPT AND
E
VENT
H
ANDLING

................................
................................
................................
............................

5

C
OMMUNICATION

................................
................................
................................
................................
.......................

6

M
EMORY
M
ANAGEMENT

................................
................................
................................
................................
............

6

D
EVELOPMENT METHODOLO
GY

................................
................................
................................
................................
.

6

Introduction

................................
................................
................................
................................
...........................

6

Host = Ta
rget

................................
................................
................................
................................
........................

6

Host! = Target

................................
................................
................................
................................
......................

7

Hybrid solutions

................................
................................
................................
................................
....................

7

S
OME PROMINENT
R
EAL
T
IME
O
PERATING
S
YSTEMS

................................
................................
................................
.

8

VXWORKS

................................
................................
................................
................................
................................
..

9

H
IGH
-
PERFORM
ANCE MICROKERNEL DES
IGN

................................
................................
................................
..............

9

S
CALABLE RUN
-
TIME SOFTWARE

................................
................................
................................
..............................

11

C
OMPREHENSIVE NETWORK
ING FACILITIES

................................
................................
................................
..............

12

POSIX

1003.1
B COMPLIANCE

................................
................................
................................
................................
..

12

I
NTERTASK
C
OMMUNI
CATION

................................
................................
................................
................................
..

13

V
IRTUAL
M
EMORY

................................
................................
................................
................................
...................

14

B
OARD
S
UPPORT
P
ACKAGES
(BSP
S
)

................................
................................
................................
........................

15

I/O

S
YSTEM

................................
................................
................................
................................
..............................

15

A
PPLICATIONS OF
V
X
W
ORKS
®:

................................
................................
................................
...............................

15

A NOTE
ABOUT THE TORNADO PL
ATFORM

................................
................................
................................

16

T
ORNADO
AE

................................
................................
................................
................................
...........................

16

T
ORNADO
II

................................
................................
................................
................................
..............................

16

REFERENCES

................................
................................
................................
................................
..........................

17


Survey Paper I

Real Time Operati
ng Systems

2


Getting Started with Real Time Operating
Systems (RTOS)

Introducti
on


The primary role of an operating system (OS) is to manage resources so as to meet the demands of target
applications. Traditional timesharing operating systems target application environments that demand
fairness
and
high resource utilization
. Real
-
tim
e applications on the other hand demand
timeliness
and
predictability,

and the operating systems targeting these applications meet these demands paying special
attention to a host of OS features like: Multitasking (ii) Synchronization (iii) Interrupt and E
vent
Handling (iv) Input/Output (v) Inter
-
task Communication vi) Timers and Clocks (vii) Memory
Management.


A real
-
time operating system (RTOS) is specialized control software that's often used in embedded
computing applications that have tight memory res
ources and stringent performance requirements relating
to immediate response times, high availability and accurate self
-
monitoring capabilities.


Any operating system that is considered to be "real
-
time" often has to adhere to a strict set of policies and

rules, with perhaps the most distinguishable feature being that a real
-
time operating system is
deterministic. For an operating system, being deterministic is a guarantee that a software system will
execute within a specified time constraint.



Real
-
tim
e systems & real
-
time operating systems


What is a real
-
time system? Different definitions of real
-
time systems exist. Here we give just a few:




Real
-
time computing is computing where system correctness depends not only on the correctness of

the logical
result of the computation but also on the result delivery time.




DIN44300: The real
-
time operating mode is the operating mode of a computer system in which the

programs for the processing of data arriving from the outside are always ready, so that their
results will

be available within predetermined periods of time. The arrival times of the data may be randomly

distributed or may already be determined depending on the different applications.




Koymans, Kuiper, Zijlstra


1988: A real
-
time System is an in
teractive system that maintains an
ongoing relationship with an asynchronous environment, i.e. an environment that progresses irrespective

of the RTS, in an uncooperative manner.




Real
-
time (software) (IEEE 610.12
-

1990): Pertaining a system or mode of
operation in which

computation is performed during the actual time that an external process occurs, in order that the

computation results may be used to control, monitor, or respond in a timely manner to the external


Survey Paper I

Real Time Operati
ng Systems

3

process.




Martin Timmerman: A real
-
ti
me system responds in a (timely) predictable way to unpredictable
external stimuli arrivals.


An RTOS should have all the features necessary to be a good building block for a RT system.


Almost every system built can have real time characteristics. For exa
mple, If your writing a paper and it
takes 3 seconds after you hit a key before the character appears on the monitor. This is not a very
favorable event but is far from saying that your system has failed. This is probably something the
designers thought mi
ght happen but choose to ignore it because it is not a disastrous event or may only
happen when the system is low on resources. However, If you are controlling a motor and it does not stop
in time resulting in disaster or death, then you have a major syste
m failure. A high priority process will
always run before the low priority process allowing the system to run processes when it needs to. The
need for a time responsive system gives rise to many practical applications.


Applications of a RTOS


There are ma
ny applications for a RTOS. If a system is responsible for controlling anything mechanical
then there is going to be some time constraints depending on the control. A guidance system for the
military needs be under very strict time constraints. If a system

is responsible for controlling a high priced
piece of artillery then it better hit whatever it is aimed at otherwise the money spent is simply not worth it

if it is just as accurate as something cheaper. Aircraft pilots need certain data now or the result
s could be
disastrous. A nuclear power plants system better be able to give accurate data and detect a possibility for a
core meltdown. If any of these systems were to fail, the result would be disaster. The airplane may not
crash, but is this a chance the

developer wants to take. Three seconds to a pilot flying a plane is much
different than the three seconds it may take for a character to appear on a PC monitor. These kind of

constraints result in the design of the OS to be thorough and highly responsive.


Types of Real
-

Time Operating Systems


There are two thoughts of mind when it comes to a real
-
time operating system.


Those that have critical time constraints and those that have softer time constraints. This is what
differentiates the two types of RT
OS's discussed in this section. These two types are the hard real
-
time
operating system, and the soft real
-
time operating systems.


Hard Real
-

Time Operating Systems


The hard real
-
time system is required to complete a critical task within a guaranteed a
mount of time. A
process is submitted along with the time necessary to complete its operations. The scheduler then does
one of two operations:



Survey Paper I

Real Time Operati
ng Systems

4



The first would be the allowance of the process, guaranteeing that the process will be completed
on time.



The second would be the rejection of the process. This is known as resource reservation. This
type of guarantee requires that the scheduler knows the exact length of time each type of process
the operating system to perform.

Therefore, each operation must

be guaranteed to take a maximum amount of time. This guarantee is
impossible in a system with a secondary storage device, or virtual memory. "Hard real
-
time systems are
composed of special
-
purpose software running on hardware dedicated to their critical p
rocesses (Galvin)."


Examples of where a hard RTOS would be used are where safety critical systems are required. The
NASA space shuttles would qualify here. The shuttle systems are often thought to be the most
complicated and critical systems designed tod
ay. On top of critical task requirements, there are
interactions with literally thousands of devices and are backed up with redundant systems. Similarly FAA
imposes a strict set of guidelines when it comes to software development for today's flight systems
, as
well does the FDA with medical equipment.



Soft Real
-
Time Operating Systems


Soft real
-
time operating systems are less restrictive by nature. A soft real
-
time system requires that the
critical processes receive priority over less critical ones. Thi
s may appear nice to start with, but it causes
an unfair allocation of resources, and may result in log delays and even starvation for processes if used or
designed incorrectly


The implementing of soft real
-
time applications requires careful design of th
e scheduler and other related
aspects of the operating system. System interactions must be known as well as the system must have
priority scheduling giving the highest priority to real
-
time processes. In addition the dispatch latency must
be small. The fas
ter a process can start execute, sooner it is runable

Examples of applications where a soft RTOS may be used are multimedia devices, graphic devices or
most commonly found appliances in our homes. Most of the software systems that have a real
-
time kernel
fall into this category from a simple remote control blender or toaster, to a teletype phone, a personal
digital assistant or even mobile phone or pager.



RTOS features


Figure 1 gives a functional diagram of an RTOS with its various components. The foll
owing discussion
delves into these components, and their desirable functionality. The main components in the functional
diagram are the hardware and the kernel of the RTOS running on top of it and servicing tasks and
interrupts that comprise the real
-
time
application. The OS has to provide, (i) task management
(scheduling, dispatching, creation and termination of tasks etc.), (ii) synchronization (for resource
sharing) (iii) interrupt handling (manipulate and monitor the interrupt descriptor table
-
IDT) to s
ervice
hardware interrupts (iv) memory management (virtual memory and dynamic memory allocation) (v)

Survey Paper I

Real Time Operati
ng Systems

5

programmable clocks and timers, and (vi) inter
-
task communication (sockets, pipes, FIFO, shared
memory etc.).




Multitasking


Multi
-
tasking involves fas
t switching between tasks allowing multiple tasks to be in a state of execution
yet only one task is executing at any instant. A RTOS must provide a minimum) a multi
-
tasking
mechanism that is priority based and preemptive in nature. It should provide suffi
cient number of priority
levels to be of practical use. For example Windows CE provides only 8 priority levels making it rather
impractical for use in a majority of real
-
time scenarios.


Synchronization


Synchronization is necessary for real
-
time tasks to

share mutually exclusive resources (devices, memory
areas, buffers etc.), which is also needed for implementing task dependence (execute statement x in task B
after task statement y in task A). Traditional solutions using semaphores (and related construct
s like
monitors, critical regions) can result in unbounded priority inversion. Priority inversion is said to occur
when a higher priority task is temporarily forced to wait for a lower priority task. Such inversion of
priority can go unbounded when medium
priority tasks preempt the lower priority task (due to lack of
resource conflicts).



Interrupt and Event Handling


For maximum productivity (and performance) it is important to allow application developers to, specify
and write interrupt handlers (Interru
pt Service Routines
-
ISRs) for Hardware Interrupts. A significant part

Survey Paper I

Real Time Operati
ng Systems

6

of a embedded real
-
time system development is writing device drivers, therefore the RTOS should
provide low level control of interrupts interrupts through interrupt handlers. Software i
nterrupts like
signals (POSIX) are also desirable.


Communication


Inter process communication (IPC) in RTOSs is primarily to exchange data on the same processor,
however with an increasing number of real
-
time systems taking a more distributed (networked)

form of
operation some RTOSs allow process communication between processes resident on different processors.
Popular forms of IPC include, shared memory, message queues, pipes, FIFOs (file in file out) and
sockets. Desirable properties of IPC mechanisms i
n the context of an RTOS include provision for non
-
blocking communication, bounded operation (r/w) latency and asynchronous communication. All the
RTOSs that provide an IPC mechanism provide the above properties. Popular IPC mechanisms in
traditional OSs l
ike sockets while being supported, have been totally rewritten to provide real
-
time
response. VxWorks supports RPC (remote procedure calls) for distributed system implementation.


Memory Management


Providing support for virtual memory is often a very diff
icult choice to make if the processor has an
MMU because, not supporting VM would amount to a waste of the MMU, while supporting it would
have the downside of non
-
determinism. VxWorks has dealt with this issue by providing virtual memory
as an optional add
-
on to the core RTOS.



Development methodology

Introduction

It is important for an RTOS to provide users with an efficient way of developing applications. Having
good, efficient tools available plays an important role in the development process, but there

is more.
Different design philosophies exist, each with their own advantages and pitfalls. Operating systems can
use different host and target configurations. The host is the machine on which the application is
developed, while the target is the machine o
n which the application executes.

Host = Target

In this configuration, the host and target are on the same machine. The RTOS has its own development

environment (compilers, debuggers) and its own command shell. With this configuration, there are no

connect
ion problems between host and target. However, the development environment is sometimes of

lesser quality, since the OS vendor often does not have sufficient resources to develop both the operating

system and the development environment. Furthermore, the R
TOS does not have all the features available
in a general
-
purpose operating system (GPOS) which facilitates development (e.g. source code control
system, backup tools, etc.).


Survey Paper I

Real Time Operati
ng Systems

7

Host! = Target

In this case, host and target are two different machines linked t
ogether (e.g. serial link, LAN, bus, etc.) for

communication purposes. The host is a machine with a proven GPOS, which is often more suitable as a

host than a machine with a dedicated RTOS. This situation often allows for a better and more complete

develop
ment environment, since all the features of the host can be used.

The drawback of this configuration comes in debugging. The debugger is on the host, while the
application is executed on the target. So
-
called debug agents are stored in the target to commun
icate
debug information to the host.

When the host and target are different machines, the development environment should provide simulators

allowing developers to execute a prototype of their application on the host by simulating the target. There

are two
ways the target can be simulated: by simulating the target microprocessor or by simulating the
target RTOS (API).


Hybrid solutions

Hybrid solutions attempt to combine the best of both worlds. The host and target are on the same physical
machine, but they
run on different operating systems that communicate with each other in some way (e.g.
via shared memory). The host OS is the rich and proven GPOS, while the target OS is the dedicated
RTOS.

In this situation, the application can be developed using all the
tools available in the GPOS, and since the
RTOS and the target application code run on the same hardware, communication between the two is not a
big issue.



Survey Paper I

Real Time Operati
ng Systems

8

Some prominent Real Time Operating Systems



RTOS

DEVELOPER

USAGE

COMMENTS

C Executive


JMI Software

Systems Inc.

San Jose


Commercial


Real time for C
programs; supports
CISC and RISC
processors


ITRON


ITRON Com
mittee,
TRON
AssociationTokyo



Commercial


Specification developed
by a Japanese
technology association;
aimed at industrial
applications


LynxOS


LynuxWorks Inc.San
Jose



Commercial


Linux
-
compatible;
supports U
nix and Java


OS
-
9


Microware

Systems Corp.Des
Moines, Iowa


Commercial


Supports Intel XScale
microarchitecture;
modular design
facilitates the addition of
new devices



VxW
orks, VxWorks AE



Wind River

Systems Inc. Alameda,
Calif.



Commercial

Segregates
applications, libraries,
data and system
software


QNX


QNX Software

Systems Ltd.Kanata,
Ontario



Commercial


Supports SCSI,
streaming

audio and
video


Chimera


Carnegie Mellon
University

Pittsburgh



Academic

Multiprocessor,
multitasking support;
designed for robotics
and automation systems


Maruti


University of

Maryland

College Park, Md.


Academic

Supports hard and soft
real
-
time

applications



Survey Paper I

Real Time Operati
ng Systems

9


VxWORKS


V
xWorks®, the run
-
time component of the Tornado!" II embedded development platform,

is the most
widely adopted real
-
time operating system (RTOS) in the embedded industry. Tornado II also includes a
comprehensive suite of core and optional cross
-
development tools and utilities and a full range of
communications options for the target conn
ection to the host.


VxWorks is flexible, with more than 1800 powerful application program interfaces (APIs); scalable, from
the simplest to the most complex product designs; reliable, used in mission
-
critical applications ranging
from anti
-
lock braking sy
stems to inter
-
planetary exploration; and available on all popular CPU
platforms.


The VxWorks RTOS comprises the core capabilities of the wind® microkernel along with advanced
networking support, powerful file system and I/O management, and C++ and other

standard run
-
time
support. These core capabilities can be combined with add
-
on components available from Wind River
Systems and its more than 320 WindLink!" for Tornado partner companies.







High
-
performance microkernel design


At the heart of the VxWorks run
-
time system is the highly efficient wind microkernel. This microkernel
supports a full range of real
-
time features including fast multitasking, interrupt support, and b
oth
preemptive and round robin scheduling. The microkernel design minimizes system overhead and enables

Survey Paper I

Real Time Operati
ng Systems

10

fast, deterministic response to external events. Each task has a separate thread of execution and is
provided with the system resources. The “wind” kern
el provides intertask synchronization and
communications facilities that facilitate the independent tasks of the real
-
time application to coordinate
their actions within the system.












The “wind” kernel also provides message queues, pipes, sockets
, and signals for intertask communication.
It comes with an optional component called “VxMP” that provides shared
-
memory objects as a
communication mechanism for tasks executing on different CPUs. The “wind” kernel uses interrupt
-
driven, preemptive priorit
y
-
based task scheduling with 256 priorities and round robin scheduling as
shown below:




Survey Paper I

Real Time Operati
ng Systems

11





The run
-
time environment also provides efficient intertask communication mechanisms, permitting
independent tasks to coordinate their actions within a real
-
time
system. The developer may design
applications using shared memory (for simple sharing of data), message queues and pipes (for intertask
messaging within a CPU), sockets and remote procedure calls (for network
-
transparent communication),
and signals (for ex
ception handling). For controlling critical system resources, several types of
semaphores are provided _ binary, counting, and mutual exclusion with priority inheritance.


Scalable run
-
time software


VxWorks is designed for scalability, enabling developers

to allocate scarce memory resources to their
application, rather than to the operating system. From deeply embedded designs requiring a few kilobytes
of memory, to complex high
-
end real
-
time systems where more operating system functions are needed,
the de
veloper may choose from over 100 different options to create hundreds of configurations.
Individual modules may be used in development and omitted in production systems.


Furthermore, these individual subsystems are themselves scalable, allowing the develo
per to optimally
configure VxWorks run
-
time software for the widest range of applications. For example, individual
functions may be removed from the ANSI C run
-
time library, or specific kernel synchronization objects
may be omitted if they are not required

by the application. Also, TCP, UDP, sockets, and standard
Berkeley network services can all be scaled in or out of the networking stack as necessary.


These configuration options can be easily selected by means of the Tornado II project facility's graphic
al
interface. Developers can also use Tornado II´s autoscaling feature, which automatically analyzes
application code and incorporates the appropriate options.



Survey Paper I

Real Time Operati
ng Systems

12

Comprehensive networking facilities


VxWorks was the first real
-
time operating system to integr
ate industry
-
standard TCP/IP networking
facilities optimized for real
-
time applications. This tradition of innovation continues with the VxWorks
TCP/IP stack, which supports the latest Berkeley networking features, including:



IP, IGMP, CIDR, TCP, UDP, ARP




RIP v.1/v.2



Standard Berkeley sockets and zbufs (a.k.a., zero
-
copy sockets)



NFS client and server, ONC RPC



Point
-
to
-
point protocol (PPP)



BOOTP, DNS, DHCP, TFTP



FTP, rlogin, telnet, rsh

Wind River also supports optional WindNet!" products: SNMP v.1/
v.2c, OSPF v.2, and STREAMS.


Wind River augments these core technologies with the industry's most extensive networking development
environment, available through the WindLink for Tornado Partner Program. Sophisticated networking
solutions include ATM, SMD
S, frame relay, ISDN, SS7, X.25, and V5 wide
-
area network protocols;
IPX/SPX, AppleTalk, and SNA local area network protocols; RMON, CMIP/GDMO and Web
-
based
solutions for distributed network management; and CORBA for distributed computing environments.


P
OSIX 1003.1b compliance


VxWorks supports the POSIX 1003.1b specification and basic system calls in the 1003.1 specification,
including process primitives, files and directories, I/O primitives, language services, and directory
handling. In addition, VxWor
ks adheres to the final approved standard for POSIX 1003.1b Real
-
Time
Extensions, including POSIX
-
compliant asynchronous I/O, counting semaphores, message queues,
signals, memory management (page locking), and scheduling control


Shared Memory
: VxWorks® pr
ovides memory sharing. But memory sharing can

pose a threat of data corruption when two or more processes try to access the

shared memory simultaneously as shown below:





Survey Paper I

Real Time Operati
ng Systems

13




This requires task synchronization and mutual exclusion, which is done using Sem
aphores in VxWorks®.
Semaphores coordinate the several tasks that are sharing the same memory and avoid data corruption.
There are four kinds of semaphores in VxWorks®:


1.
Binary Semaphores
: For synchronization and mutual exclusion. These are the fastest
and most


commonly used semaphores.


2.
Counting Semaphores
: For mutual exclusion specifically.


3.
Mutual
-
Exclusion Semaphores
: Similar to Binary Semaphores. In addition it keeps track of

number of times semaphore is given.


4.
POSIX semaphores
: POSIX d
efines both
named
and
unnamed
semaphores. The POSIX

semaphore library provides routines for creating, opening, and destroying both named and

unnamed semaphores.

The VxMP option with VxWorks® facilitates sharing of message queues and semaphores. With the
VxMP option, the above
-
mentioned inter processor communication functions are made available to entire
system. The developer may design applications using shared memory for simple sharing of data,

message queues or pipes for intertask messaging, sockets and

remote procedure calls for network
-
transparent communication, and signals for exception handling.



Intertask Communication


VxWorks® provides the following mechanism forintertask communication:


• Shared
memor
y, for simple sharing of data.


• Semaphores,

for mutual exclusion and synchronization.


• Message queues and pipes, for intertask message passing within a CPU.


• Sockets and remote procedure calls, for network
-
transparent intertask communication.


• Signals, for exception handling.


Details on Mess
age queues and Pipes
:

In VxWorks®, intertask communication within a processor is performed by “message queues”
.
Using
message queues, tasks can exchange information securely and efficiently. Message queues allow a
variable number of messages, each of varia
ble length, to be queued. Any task or ISR can send messages
to a message queue. Any task can receive messages from a message queue.


Multiple tasks can send to and receive from the same message queue. The messages are queued in FIFO
order with two prioriti
es, high and low. High priority messages are attached to the head of the queue and
low priority messages are added to the tail of the queue. Synchronization between sending and receiving
tasks is done by the message queue to avoid data corruption or loss o
f data. A task attempting to

receive a message from an empty queue is required to wait for a specific length of time, wait infinitely or
try again later. A task attempting to send a message through a queue that is already full has the same
options. This wa
y data is never lost or corrupted.



Survey Paper I

Real Time Operati
ng Systems

14






Virtual Memory

VxWorks provides both bundled and unbundled (VxVMI option) virtual memory support for boards with
an MMU (Memory Management Units), including the ability to make portions of memory non
-
cacheable
or r
ead
-
only, as well as a set of routines for virtual
-
memory management. Bundled virtual memory is
useful for multiprocessor environments where memory is shared across

processors or where DMA transfers take place.



Watchdog timers
: A watchdog timer can be us
ed to delay the execution of a task. When the watchdog
timer is activated, the task goes into a delayed state. When the delay time period elapse, an interrupt
service routine is called that returns control to the task, unless the watchdog timer is canceled

first.







Survey Paper I

Real Time Operati
ng Systems

15

Board Support Packages (BSPs)

These libraries are the heart of VxWorks portability; they provide an identical software interface to the
hardware functions of all boards. They include facilities for hardware initialization, interrupt handling
and
generation, hardware clock and timer management, mapping of local and bus memory spaces, memory
sizing, and so on.

I/O System


VxWorks® has seven basic I/O routines:
create(), remove(), open(),close(), read(), write(),
and
ioct
l().
Higher
-
level I/O ro
utines such as ANSI Compatible
print
f() and
scan
f() routines are also provided. It also
has a standard buffered I/O package
(stdi
o) that includes ANSI C
-
compatible routines such as
fope
n(),
fclos
e(),
frea
d(),
fwrit
e(),
get
c(), and
put
c(). The VxWorks® I/O
system also includes POSIX compliant
asynchronous I/O that includes a library of routines that perform I/O operations along with a task’s other
activities. VxWorks® includes device drivers for serial communication, disks, RAM disks, SCSI tape
devices, inte
rtask communication devices (called
pipe
s), and devices on a network. It also provides
facilities for additional drivers to be written by the developer. It allows dynamic installation and removal
of drivers without rebooting the system. When the user sends

an I/O request, the I/O system does very
little processing of the request and gives control of the request to the device driver. It works like a switch
in transferring the user request to the driver. Drivers can then process the request appropriately usin
g
different protocols, device specific routines, and different file systems, without any interference from the
I/O system. In addition VxWorks® also provides several high
-
level subroutine libraries for writing
drivers that implement standard protocols for
both character (file system storage devices like hard drive or
floppy drive) and block oriented devices (like terminal and printer).





Applications of VxWorks®:

Aerospace Industry
: Flight Simulators, Satellite Tracking Systems etc.

Transportation Industr
y
: ABS, Realtime Suspension, Traffic Control Systems etc.

Computer Industry
: Networking Switches, Routers, X terminals, I/O control, RAID Data
Storage, Audio/Video Systems, Postscript Laser Printer etc.

Telecommunications Industry
: PBX’s, Modems, Cellular
Systems etc.

Medical Industry
: MRI & PET Scanners, Radiation Therapy Equipment etc.

Others
: Navigation & Sonar Systems, Robotics, Digital Imaging Equipments etc.

Nortel is using VxWorks® in “Magellan Passport Enterprise Network Switch”

Jet Propulsion Labor
atories used VxWorks® in Mars Pathfinder mission.








Survey Paper I

Real Time Operati
ng Systems

16




A note about the Tornado platform


Tornado is a popular interactive development environment (IDE) from Wind River. The latest version of
Tornado is Tornado 2.2

Tornado AE

Wind River's Tornado AE p
latform features unique protection domain technology for better application
organization, isolation, and protection. Tornado AE is composed of Tornado Tools 3, the VxWorks AE
(Advanced Edition) real
-
time operating system (RTOS), and a full range of communi
cations options for
the target connection to the host. With Tornado AE, developers get the features and flexibility they need
to develop more reliable products in less time with minimal and configurable system overhead.


Tornado AE is designed for manufac
turers building service
-
critical Internet infrastructure equipment and
Internet appliances, mission
-
critical defense and aerospace systems, life
-
critical medical products and
process
-
critical industrial measurement and control systems. The platform is a 'n
o compromises' solution,
in that it delivers a highly reliable platform suitable for critical applications without compromising key
real
-
time embedded principles that have made VxWorks the most widely
-
used commercial RTOS.



Tornado II

Wind River's Torna
do II development platform has dramatically improved embedded developer
productivity. Tornado II features Tornado Tools, the high
-
performance, scalable VxWorks RTOS that
executes on the target processor, and a full range of communications options for the t
arget connection to
the host.


Tornado core tools include an integrated simulator, project facility, compiler, debugger, system browser,
and many other tools to improve software development, even before hardware is ready. Tornado supports
C, C++, and Java
development on the industry's widest range of hosts and targets, enabling developers to
choose the most appropriate hardware for their designs while leveraging their software investment and
expertise.



Survey Paper I

Real Time Operati
ng Systems

17

References


1] VxWorks programmers guide

2]
http://cs
-
www.bu.edu/pub/ieee
-
rts/Home.html


3] Real Time System Design. Levi, Shem
-
Tov, Ashok. New York: McGraw
-
Hill 1990.

4] Real Time Systems. Jane W.S. Liu. Prentice Hall

5] "Dynamic Scheduling of Har
d Real Time Applications in Open Systems Environment" 17
th

IEEE Real
Time Systems Symposium. Z. Deng, Jane W.S. Liu and J. Sun

6]
comp.os.vxworks Frequently Asked Questions [http://www.landfield.com]