REAL TIME OPERATING SYSTEM
ABSTRACT
A real-time operating system (RTOS) is an
operating system (OS) intended for real-time
applications . Such operating systems serve
application requests nearly real-time. A real-
time operating system offers programmers more
control over process priorities. Real time means
immediate response from the computer. Thus
a system in which a transaction that we access
and update a file quickly enough to affect
original decision making is called a real time
operating system. A real time operating system
has well defined time constraints.
INTRODUCTION
An operating system (OS) is a software , consisting
of programs and data that runs on computers and
manages the computer hardware and provides
common services for efficient execution of various
application software.A good operating system (OS)
provides a solid interface to the hardware and allows
the application to be managed in the most efficient
manner possible.
Real-time operating systems are software/hardware
systems in which timing
constraints must be met for correctness. “Real-time”
does not mean “really fast”, but rather “get this done
by the deadline or else you have failed.” Such hard
real-time systems are ubquitous and vital in a range
of places from everyday life to
estoteria:
• The ignition, fuel injection, and timing of most car
engines is handled by a real-time system.
• The antilock brake system in most cars is a real-time
system.
. which not reacting in a certain interval of time would
• The software of the Mars Rovers is architected
around VxWorks, a commercial real-time operating
system.Most hard real-time systems are embedded
systems, meaning the software is
codesigned with the hardware, under often severe cost
constraints, to accomplish a specific task. The user
doesn't see the system as a general purpose computer.
Soft real-time systems are penalized by how much
they miss the desired deadlines and by the variance of
their latency. Such systems show up in many familiar
places in general purpose computers, or should:
• Media playback
• Scientific visualization
• Games
• Interactive applications
Distributed real-time systems are those which have
multiple resources with non-negligible latency among
them. Examples include the multiple processors in a
car, or media being streamed
The term real-time derives from its use in early
simulation. While current usage implies that a
computation that is 'fast enough' is real-time,
originally it referred to a simulation that proceeded at
a rate that matched that of the real process it was
simulating. Analog computer especially, were often
capable of simulating much faster than real-time, a
situation that could be just as dangerous as a slow
simulation if it were not also recognized and
accounted for.
Hard and soft real-time systems
A system is said to be ''real-time'' if the total
correctness of an operation depends not only upon its
logical correctness, but also upon the time in which it
is performed. The classical conception is that in a
'''hard real-time''' or '''immediate real-time system''',
the completion of an operation after its deadline is
considered useless - ultimately, this may cause a
critical failure of the complete system. A '''soft real-
time system''' on the other hand will tolerate such
lateness, and may respond with decreased service
quality (e.g., omitting frames while displaying a
video).
Hard real-time systems are used when it is imperative
that an event is reacted to within a strict deadline.
Such strong guarantees are required of systems for
cause great loss in some manner, especially damaging
the surroundings physically or threatening human
lives (although the strict definition is simply that
missing the deadline constitutes failure of the system).
For example, a [automobile|car] [engine] control
system is a hard real-time system because a delayed
signal may cause engine failure or damage. Other
examples of hard real-time embedded systems include
medical systems such as heart[artificial pacemaker|
pacemaker] and industrial process controllers. Hard
real-time systems are typically found interacting at a
low level with physical hardware, in [[embedded
system]]s. Early video game systems such as the
[[Atari 2600]] and [[Cinematronics]] vector graphics
had hard real-time requirements because of the nature
of the graphics and timing hardware.
Soft real-time systems are typically used where there
is some issue of concurrent access and the need to
keep a number of connected systems up to date with
changing situations; for example software that
maintains and updates the flight plans for commercial
[[airline]]rs. The flight plans must be kept reasonably
current but can operate to a latency of seconds.
RECENT WORK IN FIELD
The 31st IEEE Real-Time Systems Symposium
(RTSS) in San Diego, California, will follow the
format of recent RTSSs, with multiple tracks. RTSS is
the premier conference in the area of real-time
computing, presenting innovations in the field with
respect to theory and practice.
RTSS provides a forum for the presentation of high-
quality, original research covering all aspects of real-
time systems design, analysis, implementation,
evaluation, and experiences. RTSS’10 continues the
trend of making RTSS an expansive and inclusive
symposium, looking to embrace new and emerging
areas of real-time systems research.
RTSS’10 welcomes the submission of mature papers
in several areas of real-time computing, including but
not limited to scheduling; databases; observability;
composability; security for real-time systems; tools
and reduction to practice; control and adaptive RT
systems theory; testing and debugging; modeling;
formal methods; communications (wireless, wireline,
and sensor networks); power, thermal, and energy
management; embedded systems; sensor and
implantable devices; robustness; fault tolerance and
robustness; intelligent behavior; time-sensitive
robotics; emergency/disaster management; embedded
real-time systems and infrastructures; QoS support;
real-time systems middleware, and cyber-physical
systems.
SCOPE FOR THE RESEARCH
WORK RELATED DATA
INtime is implemented as a real-time operating
system which shares the hardware platform with the
Windows operating system. Components installed on
Windows include a Windows kernel driver and a
number of Windows services. The driver manages
memory for the kernel and real-time applications to
run in, and manages the communications
interface between the two systems.
A Windows service loads the real-time kernel into the
allocated memory and then causes a context switch
from Windows to the INtime kernel. A low-priority
thread is created whose function is to switch the
machine context back to the Windows system.
Because this thread will be preempted by all other
real-time threads, as far as the real-time kernel is
concerned, the Windows system is the real-time
system's idle task.
When in the INtime context, any real-time interrupts
are handled directly, and all other interrupts are
masked at the interrupt controller. When the context
returns to Windows, these interrupts are unmasked to
allow normal processing by Windows. When a real-
time interrupt occurs in the Windows context, the
Windows IDT is patched so as to cause a context
switch to the INtime context so the interrupts may be
handled.
The system timer is usually shared between Windows
and INtime. The hardware timer is reprogrammed to
interrupt at a higher rate than Windows requires, and
the Windows handler is only invoked as required.
Typically, the INtime kernel takes timer interrupts at a
much higher rate (a period as low as 100µs is
possible) to allow for finer granularity timing services.
Optimization of the timer handling avoids
unnecessary context switches between Windows and
INtime.
Certain hardware abstraction layer (HAL) entry points
are intercepted and monitored in order to prevent the
Windows kernel from performing unwanted actions
such as masking a real-time interrupt, or changing the
hardware system timer frequency. The HAL file is not
modified or replaced by the software.
The INtime kernel provides operating system services
for the real-time virtual machine. It provides the real-
time services expected of such a kernel, consisting of
a priority-based preemptive scheduler with priority-
based interrupt handling. Thread priorities range from
0 (highest priority) to 255 (lowest priority) and
threads below a configurable priority threshold can
time-slice with threads of equal priority. The kernel
scheduler has been optimized for maximum interrupt
performance.
The resulting platform exhibits good performance,
and above all its behavior is predictable.
Win32 API
Win32 API lacks some useful features for real-time
programming, INtime provides a Win32 API for
ease of transporting code from Windows
applications. This implementation is a rich subset of
the Windows CE Win32 implementation, including a
useful subset of Win32 objects,
WaitForMultipleObjects, and with extensions to
manage interrupts and Peripheral Component
Interconnect (PCI) bus configuration
Windows APIs
APIs are provided for Windows applications to allow
them to share objects created on the real-time kernel.
Both standard real-time objects and Win32 objects are
shareable so that Windows and real-time applications
may synchronize and share data. Blocking calls are
handled by a pool of proxy threads on the real-time
kernel.
C Library and C++ Support
Embedded C++) ANSI standard, with the Standard
Template Library (STL). INtime provides an
American National Standard Institute (ANSI-
compatible) C library, and support for the EC++ (
Other Services
A Transmission Control Protocol/Internet Protocol
(TCP/IP) stack is provided which is derived from the
BSD Net3 architecture. Ethernet drivers are provided
for Intel, 3Com, and Realtek interface adapters, as
well as for NE2000-compatible ISA interfaces. Serial
links are supported through Serial Line Internet
Protocol (SLIP).
USB support is provided as a development kit for
developing USB client software. Standard drivers are
provided for Universal Host Controller (UHCI), Open
Host Controller (OHCI), and Enhanced Host
Controller (EHCI) interfaces.
Other drivers are provided for a range of standard and
industrial interface.
PRESENTATION WORK
queue to have a greater number of overall tasks in the
ready to be executed state Usually the data structure
of the ready list in the scheduler is designed to
minimize the worst-case length of time spent in the
scheduler's critical section, during which preemption
REAL TIME SCHEDULING
In typical designs, a task has three states: 1) running
(executing on the CPU), 2) ready (ready to be
executed), 3) blocked (waiting for input/output). Most
tasks are blocked or ready most of the time because
generally only one task can run at a time per CPU.
The number of items in the ready queue can greatly
vary, depending on the number of tasks the system
needs to perform and the type of scheduler that the
system uses. On simpler non-preemptive but still
multitasking systems, a task has to give up its time on
the CPU to other tasks, which can cause the ready is
inhibited, and, in some cases, all interrupts are
disabled. But the choice of data structure depends also
on the maximum number of tasks that can be on the
ready list.
If there are never more than a few tasks on the ready
list, then a doubly linked list of ready tasks is likely
optimal. If the ready list usually contains only a few
tasks but occasionally contains more, then the list
should be sorted by priority. That way, finding the
highest priority task to run does not require iterating
through the entire list. Inserting a task then requires
walking the ready list until reaching either the end of
the list, or a task of lower priority than that of the task
being inserted.
Care must be taken not to inhibit preemption during
this search. Longer critical sections should be divided
into small pieces. If an interrupt occurs that makes a
high priority task ready during the insertion of a low
priority task, that high priority task can be inserted
and run immediately before the low priority task is
inserted.
The critical response time, sometimes called the
flyback time, is the time it takes to queue a new ready
task and restore the state of the highest priority task to
running. In a well-designed RTOS, readying a new
task will take 3 to 20 instructions per ready-queue
entry, and restoration of the highest-priority ready task
will take 5 to 30 instructions.
In more advanced systems, real-time tasks share
computing resources with many non-real-time tasks,
and the ready list can be arbitrarily long. In such
systems, a scheduler ready list implemented as a
linked list would be inadequate.
Algorithms
Some commonly used RTOS scheduling algorithms
are:
• Cooperative scheduling
• Preemptive scheduling
• Round-robin scheduling
• Fixed priority pre-emptive scheduling, an
implementation of preemptive time slicing
Fixed-Priority Scheduling with Deferred
Preemption
• Fixed-Priority Non-preemptive Scheduling
Critical section preemptive scheduling
• Static time scheduling
• Earliest Deadline First approach
• Non-Preemptive: Non-preemptive algorithms are designed so that once a process
enters the running state(is allowed a process), it is not removed from the processor
until it has completed its service time ( or it explicitly yields the processor).
CONCLUSION
If users have at their disposal a DO-178B Level A
certifiable system, most of the work for a high-
assurance OS is already done. The NSA and
embedded-OS industry consensus is that most of the
work will be in formal methods necessary to achieve
an EAL 7 rating, provided that the kernel is kept
small and only provides the minimal functionality to
support information flow and data isolation.
LynuxWorks' own research has show that a working
prototype system with the separation kernel to
demonstrate functionality. An external agency will be
used to achieve formal methods certification to EAL
7.
LynuxWorks is pioneering in this technology.
Currently, LynuxWorks offers an RTOS that is
certified by the FAA to the DO-178B Level A
standard. As mentioned above, this product
(LynxOS-178 ) can be easily certified to the
Common Criteria EAL [4]. LynuxWorks is building
on this technology to be able to deliver a real_time
operating system certifiable to the Common
Criteria EAL 7.
REFERENCES
Mark Vanfleet, "MASK Mathematically Assured
Separation Kernel, Separation Kernel Paradigm",
NSA
RTCA. DO-178B/ED-12B. Software Considerations
in Airborne Systems and Equipment Certification.
RTCA, 1992
J. Alves-Foss, C. Taylor, and B. Rinker. "Merging
Safety and Assurance: The Process of Dual
Certification for Software", 2002,
http://www.csds.uidaho.edu/papers/Taylor02d
.pdf .
NIST. Common Criteria for W Information Security
Evaluation. Parts 1, 2, 3, 1999.
YOUR CONTRIBUTION
My experience was very good in using REAl TIME
OPERATING SYSTEM.I found is to be very
powerful,robust and strong real-time,and explain to
others.
 • context_switch() is called only when the process terminates or blocks.
• Preemptive: Preemptive algorithms are driven by the notion of prioritized
computation. The process with the highest priority should always be the one currently
using the processor. If a process is currently using the processor and a new process
with a higher priority enters, the ready list, the process on the processor should be
removed and returned to the ready list until it is once again the highest-priority
process in the system
• context_switch() is called even when the process is running usually done via a
timer interrupt

• contribution

This paper presents and discusses a special case of

RTPS in which the state variable changes following an
exponential behavior. The goal is to schedule resources
using traditional real-time scheduling algorithms while
achieving some given constraints on the state variable. In
particular, we provide results regarding the working range
of the state variable, i.e., we are interested in bounding the
physical value within a given range. For this purpose, we
relate real-time parameters of scheduled resources to the
bounds of the working range.
Despite we focus on a specific RTPS, the proposed
model and results are general enough to model several real
physical systems. In fact, the exponential behavior of the
proposed RTPS arises froma modelization based on affine
time-invariant dynamic systems, which can describemany
existing physical systems. For this purpose, a differential
equation is associated to each real-time resource which
determine the physical value behavior. [1] R. Braden. D. and Clack. S. Shenker,
"Integrated Service in the internet Architecture: an Overview,"RFC 1633. June 1994
[2] Paul P. Write. "RSVP and Integrated Services in the internet: A Tutorial," IEEE
Communications
Area in Comm. Vol. 9. No. 9. pp. 1524- Magazine. pp.100-106. May. 1997.
[3] W.T.Chen. and C. F. Huang. and S. C. Ding."A Scheme for QoS Control in ATM
Switching Systems," J. of High Speed Networks. pp.221-236. June. 1997..
[4] A. Y. M Lin. and J. A. Silvester. "Priority
Queueing Strategies and Buffer Allocation
Protocols for Traffic Control at an ATM Integrated Broad-band Switching System,"
IEEE J. on Sel.1536. Dec.1991.
[5] L. Li. C. Hu. and P. Liu. "Maximum Throughput of an Input Queueing Packet
Switch with Two Priority Classes," IEEE Trans. on Comm. Vol. 42. No. 12. pp.3095-
3097. Dec. 1994
[6] K.W.Ross and E.biersack. "Topology Centric Lookup Service," 5th. Int.
Workshop Network Group Communications, NGC. 2003.
[7] T.Takine. and B. Sengupta. T. Hasegawa. "An Analysis of a Discrete-Time Queue
for Broadband ISDN with Priorities among Trafic Classes," IEEE Trans. on Comm.
Vol. 42. No. 2. pp. 1837-1845.Feb. 1994
[8] I. Stavrakakis, "Delay Bounds on a Queueing System with Consistent Priorities."
IEEE Trans. On Comm Vol. 42. No. 2/3/4, pp.615-624.Feb./Mar./Apr. 1994
[9] S. Keshav. REAL 5.0 Overview.
http://www.cs.cornell.edu/skeshav/real/overview.html
[10] J.F. Kurose and K.W. Ross, Computer
Networking, Addison Wesley, 2009.
Contribution:This paper presents and discusses a special case of RTPS(REAL TIME
POLLING SERVICE) in which the state variable changes following an exponential
behavior. Despite we focus on a specific RTPS, the proposed model and results are
general enough to model several real physical systems. In fact, the exponential behavior
of the proposed RTPS arises froma modelization based on affine time-invariant
dynamic For this purpose differential equation is associated to each real-time resource
which determine the physical value behavior.

systems, wh provides common services for efficient execution of various application software.A good
operating system (OS) provides a solid interface to the hardware and allows the application to be managed in
the most efficient manner possible.
A real-time operating system (RTOS) is an operating system (OS) intended for real-time applications . Such
operating systems serve application requests nearly real-time. A real-time operating system offers
programmers more control over process priorities. Real time means immediate response from the
computer. Thus a system in which a transaction that we access and update a file quickly enough to
affect original decision making is called a real time operating system. A real time operating system has
well defined time constraints.
A real-time system is one in which time plays an essential role.Typically, one or more physical devices external
to the generate stimuli,and the computer must react appropriately to them within a fixed amount of time. For
example, the computer in a compact disc player gets the bits as they come off the drive and must convert them
into music within a very tight time interval.If the calculation takes too long, the music will sound peculiar.Other
real-time systems are patient monitoring in a hospital intensive care unit,the autopilot in an aircraft, and robot
control in an automated factory.In all these cases, having the right answer but having it too late is often just as
bad as not having it at all.

• Real-time systems are generally categorized as hard real time,meaning there are absolute deadlines that
must be met,or else ,soft real time,meaning that missing an occasional deadline is undesirable,but
nevertheless tolerable.The events a real-time system may have to respond to can be further categorized
as periodic(occurring at regular intervals) or aperiodic ich can describe many existing