Introduction To Real-Time Operating Systems

Introduction To Real-Time
Operating Systems
• What are Real-time Embedded systems?
• The embedded system which processes real time
input data from various units to produce a meaningful
result.
• It mostly has RTOS.
• Very Stringent operating criteria w.r.t. time
• Soft-real time and Hard real time systems.
• In a soft real time systems, deadline can be exceeded
by a small fraction of time.(1msec = 1.05msec)
• In a hard real time system, deadline very stringent.
1msec = 1.0000000msec only
• Characteristics of Real-Time Embedded Systems
• Structure:
• A real-time embedded system interacts with its
environment continuously and timely.
• To retrieve data from its environment – the target
that it controls or monitors, the system must have
sensors in place.
• Since the signals in nature are analog these have to be
converted into digital. ADC is required.
• The brain of an embedded system is a controller,
along with memory, peripherals etc.
• The controller acts upon the target system through
actuators.
• Real-Time Response:
• A real-time system or application has to finish certain
tasks within specified time boundaries.
• This is the character that distinguishes a real-time
system from a non-real-time system.
• The ABS is a typical real-time system.
• When the sensors detect a dramatic deceleration of
wheels, the system must act quickly to prevent the
wheels from being locked up; otherwise, a disaster
may occur.
• Moreover, the control law computing is also real-
time.
• Highly constrained Environment:
• Real-time embedded systems are often run in highly
resource-constrained environments.
• This makes the system design and performance
optimization quite challenging.
• Sometimes the ES is expected to work in harsh, high
temperature conditions.
• Concurrency:
• Concurrency refers to a property of systems in which
several computations are executing simultaneously
and potentially interacting with each other.
• Physical environment is by its nature concurrent –
multiple processes occur at the same time.
• The aim is to meet all the deadlines, with optimum
response time to all events.
• Predictability:
• A real-time system must behave in a way that can be
predicted in terms of all timing requirements.
• A real-time system such as an ABS, or an airplane’s
flight-control system, must always be 100%
predictable, or human lives are at stake.
• Many real-time embedded systems contain
heterogeneous computing resources, memories, bus
systems etc.
• This can make a system unpredictable.
• In brief, the system is expected to be deterministic.
• Safety and Reliability
• Hard and Soft Real-Time Embedded Systems:
• A hard real-time system is a system in which most
timing constraints are hard.
• The ES must and should give deterministic output
well within some time constraint.
• Otherwise the computation results into junk or worst
case failure.
• On the other hand, a soft constraint is a constraint
that a system should meet.
• But when the deadline is occasionally missed, it
won’t cause any disastrous result, and the delivered
service is still useful to a certain extent.
• Hard and Soft Real-Time Embedded Systems:
• The wheel speed sensors must be polled every 15
milliseconds.
• Each cycle, the control law computation for wheel
speed must be finished in 20 milliseconds.
• Each cycle, the wheel speed prediction must be
completed in 10 milliseconds.
Real-Time Operating Systems
• The heart of many computerized embedded systems
is real-time operating system (RTOS).
• RTOS should support the construction of applications
that must meet real-time constraints.
• It provides mechanisms and services to carry out
real-time
• task scheduling.
• resource management.
• intertask communication.
• A GPOS: An overview
• An OS is a policy enforcer.
• An OS is composed of multiple software components,
and the core components in the OS form its kernel.
• The kernel provides the most basic level of control
over all of the computer’s hardware devices.
• A kernel always runs in system mode while an user
application always runs in user mode.
• The kernel is protected from illegal access by the
user application.
• Characteristics of RTOS Kernels
• Although a general-purpose OS provides a rich set of
services that are also equally important for RTOS.
• However GPOS consume lot of memory space and
considerable CPU execution time.
• The kernel is very big in size in terms of execution
space.
GPOS
• In a given time span of say 10msec, a GPOS

consumes upto 30% of the time executing itself.
RTOS
• Generally an RTOS consumes hardly 1% of the time

frame leaving most of the time for the application
program.
• Therefore an RTOS is very small in code size as
compared to a GPOS.
• There are three key requirements of RTOS design:
• The timing behavior of the OS must be predictable.
• For all services provided by the OS, the upper bound
on the execution time must be known.
• The OS must manage the timing and scheduling, and
the scheduler must be aware of task deadlines.
• The OS must be fast. For example, the overhead of
context switch should be short.
• A high-level view of RTOS
• Priority Scheduling:
• all tasks are not equal in terms of the urgency of
getting executed.
• Tasks with shorter deadlines should be scheduled for
execution sooner than those with longer deadlines.
• Therefore, tasks are typically prioritized in an RTOS.
• Moreover, if a higher priority task is released while the
processor is serving a lower priority task,
• the RTOS should temporarily suspend the lower
priority task .
• immediately schedule the higher priority on the
processor for execution, to ensure that the higher
priority task is executed before its deadline. Pre-
emption is always evident in RTOS
• Task scheduling for real-time applications is typically
priority-based and preemptive.
• Ex: earliest deadline first (EDF) scheduling and rate
monotonic (RM) scheduling.
• FCFS, SJF, RR are not suitable for an RTOS.
• Intertask Communication and Resource Sharing:
• In an RTOS, a task cannot call another task. Instead,
tasks exchange information through message passing
or memory sharing.
• Real-Time Signals
• Signals are similar to software interrupts.
• In an RTOS, a signal is automatically sent to the
parent when a child process terminates.
• The processes are informed of any asynchronous
event through signals.
• One such class of signals is the Semaphore
• Semaphores are counters used for controlling access
to resources shared among processes or threads.
• Semaphores:
• Semaphores are counters used for controlling access
to resources shared among processes or threads.
• The value of a semaphore is the number of units of
the resource that are currently available.
• There are two basic operations on semaphores.
• One is to atomically increment the counter.
• The other is to wait until the counter is non-null and
atomically decrement it.
• A semaphore tracks only how many resources are
free and not of what type of resources.
• A binary semaphore is known as mutex.
• Message Passing:
• tasks can share data by sending messages in an
organized message passing scheme.
• Message passing is much more useful for information
and it can also be used for process- synchronization.
• Message passing often coexists with shared memory
communication.
• Two basic operations are send and receive.
• Message passing can be direct or indirect.
• In direct message passing, each process wanting to
communicate must explicitly name the recipient or
sender of the communication.
• In indirect message passing, messages are sent to and
received from mailboxes or ports.
• SharedMemory:
• Shared memory is a method that an RTOS uses to
map common physical space into independent
process-specific virtual space.
• Shared memory is commonly used to share
information (resources) between different processes
or threads.
• Therefore, it is necessary to use mutex semaphores
to protect the memory area.
• The code segment in a task that accesses the shared
data is called a critical section.
• A side effect in using shared memory is that it may
cause priority inversion.
• A situation that a low-priority task is running while a
high-priority task is waiting.
• Memory Locking
• Memory locking is a real-time capability specified by
POSIX that is intended for a process to avoid the
latency of fetching a page of memory.
• It is achieved by locking the memory so that the page
is memory-resident, that is, it remains in the main
memory.
• This allows fine-grained control of which part of the
application must stay in physical memory.
• This reduces the overhead associated with
transferring data between memory and disk.
• When the process exits, the locked memory is
automatically unlocked.
• For example, memory locking can be used to keep in
memory a thread that monitors a critical process that
requires immediate attention.
• Task scheduling:
• Periodic tasks: Periodic tasks are repeated once a
period, for example, 200 milliseconds.
• They are time-driven.
• Periodic tasks typically arise from sensory data
acquisition, control law computation.
• Such activities need to be cyclically executed at
specific rates, which can be derived from the
application requirements.
• However periodic tasks have very hard deadlines.
• Aperiodic tasks. Aperiodic tasks are one-shot tasks.
• For example, a driver may change the vehicle’s cruise
speed while the cruise control system is in operation.
• To maintain the speed set by the driver, the system
periodically takes its speed signal from wheel speed
sensor.
• When the user manually changes the speed, the
system has to respond to the change and meanwhile
keeps its regular operation.
• Aperiodic tasks either have no deadlines or have soft
deadlines.
• Sporadic tasks. Sporadic tasks are also event-driven.
• The arrival times of sporadic task instances are not
known a priori.
• sporadic tasks have hard deadlines.
• For example, when the driver of a vehicle sees a
dangerous situation in front of him.
• The Cruise control is still active.
• But since the driver pushes the brakes very hard, the
RTOS has to take care of this situation.
• Tasks in real time are not equally important. Some
are critical, some are not.
• Some tasks are pre-emptable, while some are not.
• Each task executes within its own context.
• Only one task within the application can be executing
at any point in time on a processor.
• A schedule is an assignment of tasks to available
processors.
• A schedule is an assignment of tasks to available
processors.
• The scheduler of an RTOS is a module that
implements the assignment (scheduling) algorithms.
• Priority-Driven Scheduling Algorithms
• online scheduling, and decisions are made at
runtime.
• Priority assignment can be done statically or
dynamically while the system is running.
• Fixed Priority
• RM Rate Monotonic Scheduling
• Deadline-Monotonic Algorithm
• Dynamic-Priority
• Earliest-Deadline-First (EDF) Algorithm
All these algorithms have a schedulability test.
• RTOS
scheduling criteria:
• Rate Monotonic Least Upper Bound:
• Given a set of services Si ,
• their completion times Ci
• Their release periods Ti
• These set of services are supposed or expected to
meet the deadlines if
• ≤ m(m1/2 - 1)
• Where m= number of services in a given set.
• This is known as the sufficient condition to predict
whether a given set of services will meet the
deadlines.
• Ex1:
Assume a two process service set with C1 = 1, C2 = 1
and T1 = 2, T2 = 5. Determine whether the set of
services is feasible to be scheduled as per RM policy.
• Find the utility U = ½ + 1/5 = 0.7
• Calculate the LUB condition 2(21/2 - 1) = 0.83
• The set of processes is feasible and will never miss
the deadline.
• Ex2:
• Assume a two process service set with C1 = 1, C2 = 2
and T1 = 2, T2 = 5. Determine whether the set of
services is feasible to be scheduled as per RM policy.
• Find the utility U = ½ + 2/5 = 0.9
• Calculate the LUB condition 2(21/2 - 1) = 0.83
• What is your answer? Feasible or not feasible?
• Timing diagram:
We assume that the time slice for each process is equal
to 1 unit.
• CI
• It can be observed that both S1 and S2 meet the
deadlines.
• Even though they appear to fail the suffient condition
in RM policy.
• This means that sufficient condition is not enough to
predict whether a process will meet the deadline or
not.
• Necessary and sufficient feasibility testing :
• Scheduling point test
• Completion Time test
• Scheduling point test :
• Assume that the worst case, all services are
requested at the same time.
• An iterative test is defined as follows:
Deadline monotonic scheduling
• This is another scheduling policy for real time
applications.
• This is very similar to RM scheduling policy and a
fixed priority scheduling policy.
• The RM policy assumes that service period must be
equal to service deadline.
• But DM policy removes this restriction such that
deadline can be less than the release period.
Numericals
• Check whether the following service set with two
services is feasible for both RM and DM policy:
T1 = 20msec, T2 = 50msec, C1 = 10msec, C2 = 20msec

Introduction To Real-Time Operating Systems

Uploaded by

Copyright:

Available Formats

Introduction To Real-Time Operating Systems

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Introduction To Real-Time Operating Systems

Uploaded by

Copyright:

Available Formats

Introduction To Real-Time

• In a given time span of say 10msec, a GPOS

• Generally an RTOS consumes hardly 1% of the time

You might also like