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.
• Characteristics of Real-Time Embedded Systems
• 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.
• Characteristics of Real-Time Embedded Systems
• 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.
• Characteristics of Real-Time Embedded Systems
• 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.
• Characteristics of Real-Time Embedded Systems
• 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