Download Getting Started with Real Time Operating Systems (RTOS)

Real Time Operating Systems
Survey Paper I
Author(s):
Amit Sharma, Ali Abbas, Dhaval Sanghvi
Document Version:
1.0
Document Status:
Open
Document Release Date:
October 5, 2002
Security Classification:
Not confidential
i
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
operating systems such as processes, tasks, semaphores, process states and memory
management is assumed.
ii
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 area of Real Time Operating Systems (RTOS). It serves as a help guide
for the concepts of RTOS in general and VxWorks in particular.
iii
Table of Contents
REAL TIME OPERATING SYSTEMS .................................................................................................................... I
SURVEY PAPER I ......................................................................................................................................................... I
AUDIENCE .................................................................................................................................................................II
INTENT OF THIS DOCUMENT ........................................................................................................................... III
TABLE OF CONTENTS ............................................................................................................................................1
GETTING STARTED WITH REAL TIME OPERATING SYSTEMS (RTOS) ..................................................2
INTRODUCTION ...........................................................................................................................................................2
REAL-TIME SYSTEMS & REAL-TIME OPERATING SYSTEMS ..........................................................................................2
APPLICATIONS OF A RTOS .........................................................................................................................................3
TYPES OF REAL- TIME OPERATING SYSTEMS ..............................................................................................3
HARD REAL- TIME OPERATING SYSTEMS...................................................................................................................3
SOFT REAL-TIME OPERATING SYSTEMS .....................................................................................................................4
RTOS FEATURES ......................................................................................................................................................4
MULTITASKING ..........................................................................................................................................................5
SYNCHRONIZATION ....................................................................................................................................................5
INTERRUPT AND EVENT HANDLING ............................................................................................................................5
COMMUNICATION .......................................................................................................................................................6
MEMORY MANAGEMENT............................................................................................................................................6
DEVELOPMENT METHODOLOGY .................................................................................................................................6
Introduction ...........................................................................................................................................................6
Host = Target ........................................................................................................................................................6
Host! = Target ......................................................................................................................................................7
Hybrid solutions ....................................................................................................................................................7
SOME PROMINENT REAL TIME OPERATING SYSTEMS .................................................................................................8
VXWORKS ..................................................................................................................................................................9
HIGH-PERFORMANCE MICROKERNEL DESIGN..............................................................................................................9
SCALABLE RUN-TIME SOFTWARE .............................................................................................................................. 11
COMPREHENSIVE NETWORKING FACILITIES .............................................................................................................. 12
POSIX 1003.1B COMPLIANCE .................................................................................................................................. 12
INTERTASK COMMUNICATION .................................................................................................................................. 13
VIRTUAL MEMORY ................................................................................................................................................... 14
BOARD SUPPORT PACKAGES (BSPS) ........................................................................................................................ 15
I/O SYSTEM .............................................................................................................................................................. 15
APPLICATIONS OF VXWORKS®: ............................................................................................................................... 15
A NOTE ABOUT THE TORNADO PLATFORM ................................................................................................ 16
TORNADO AE ........................................................................................................................................................... 16
TORNADO II.............................................................................................................................................................. 16
REFERENCES .......................................................................................................................................................... 17
Survey Paper I
Real Time Operating Systems
1
Getting Started with Real Time Operating
Systems (RTOS)
Introduction
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-time 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 Event
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 resources 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-time 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 interactive 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 Operating Systems
2
process.
– Martin Timmerman: A real-time 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 example, 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 might 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 system 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 many 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 results 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 RTOS'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 amount 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 Operating Systems
3
 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 processes (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 today. 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. This 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 the 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 faster 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 following 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 service
hardware interrupts (iv) memory management (virtual memory and dynamic memory allocation) (v)
Survey Paper I
Real Time Operating Systems
4
programmable clocks and timers, and (vi) inter-task communication (sockets, pipes, FIFO, shared
memory etc.).
Multitasking
Multi-tasking involves fast 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 sufficient 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 constructs 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 (Interrupt Service Routines -ISRs) for Hardware Interrupts. A significant part
Survey Paper I
Real Time Operating Systems
5
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 interrupts 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 in the context of an RTOS include provision for nonblocking 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 like 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 difficult 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 on 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
connection 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 RTOS 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 Operating Systems
6
Host! = Target
In this case, host and target are two different machines linked together (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
development 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 communicate
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 Operating Systems
7
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 Committee,
TRON
AssociationTokyo
Commercial
Specification developed
by a Japanese
technology association;
aimed at industrial
applications
LynxOS
LynuxWorks Inc.San
Jose
Commercial
Linux-compatible;
supports Unix and Java
OS-9
Microware
Systems Corp.Des
Moines, Iowa
Commercial
Supports Intel XScale
microarchitecture;
modular design
facilitates the addition of
new devices
VxWorks, 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 Operating Systems
8
VxWORKS
VxWorks®, 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
connection
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 systems 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 both
preemptive and round robin scheduling. The microkernel design minimizes system overhead and enables
Survey Paper I
Real Time Operating Systems
9
fast, deterministic response to external events. Each task has a separate thread of execution and is
provided with the system resources. The “wind” kernel 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 interruptdriven, preemptive priority-based task scheduling with 256 priorities and round robin scheduling as
shown below:
Survey Paper I
Real Time Operating Systems
10
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 exception 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 developer 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 developer 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 graphical
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 Operating Systems
11
Comprehensive networking facilities
VxWorks was the first real-time operating system to integrate 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, SMDS, 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.
POSIX 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, VxWorks 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® provides 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 Operating Systems
12
This requires task synchronization and mutual exclusion, which is done using Semaphores 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 defines 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 networktransparent communication, and signals for exception handling.
Intertask Communication
VxWorks® provides the following mechanism forintertask communication:
• Shared memory, 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 Message 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 variable 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 priorities, 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 of 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 way data is never lost or corrupted.
Survey Paper I
Real Time Operating Systems
13
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 read-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 used 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 Operating Systems
14
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 ioctl().
Higher-level I/O routines such as ANSI Compatible printf() and scanf() routines are also provided. It also
has a standard buffered I/O package (stdio) that includes ANSI C-compatible routines such as fopen(),
fclose(), fread(), fwrite(), getc(), and putc(). 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, intertask communication devices (called pipes), 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 using
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 Industry: 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 Laboratories used VxWorks® in Mars Pathfinder mission.
Survey Paper I
Real Time Operating Systems
15
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 platform 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 communications 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 manufacturers 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 'no 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 Tornado 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 target 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 Operating Systems
16
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 Hard Real Time Applications in Open Systems Environment" 17th 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]
Survey Paper I
Real Time Operating Systems
17