Real Time System
A system is said to be Real Time if it is required to
complete it’s work & deliver it’s services on time.
Example – Flight Control System
All tasks in that system must execute on time.
Non Example – PC system
Hard and Soft Real Time Systems
Hard Real Time System
Failure to meet deadlines is fatal
example : Flight Control System
Soft Real Time System
Late completion of jobs is undesirable but not fatal.
System performance degrades as more & more jobs miss deadlines
Online Databases
Hard and Soft Real Time Systems
(Operational Definition)
Hard Real Time System
Validation by provably correct procedures or extensive simulation that the
system always meets the timings constraints
Soft Real Time System
Demonstration of jobs meeting some statistical constraints suffices.
Example – Multimedia System
25 frames per second on an average
Role of an OS in Real Time Systems
Standalone Applications
Often no OS involved
Micro controller based Embedded Systems
Some Real Time Applications are huge & complex
Multiple threads
Complicated Synchronization Requirements
Filesystem / Network / Windowing support
OS primitives reduce the software design time
Real-time and embedded systems operate in
constrained environments in which computer
memory and processing power are limited.
They often need to provide their services within
strict time deadlines to their users and to the
surrounding world.
It is these memory, speed and timing constraints
that dictate the use of real-time operating
systems in embedded software.
RTOS
A variant of OS that operates in constrained environment
in which computer memory and processing power is
limited.
Moreover they often need to provide their services in
definite amount of time.
Hard, Soft & Firm RTOS
Example RTOS: VxWorks, pSOS, Nucleus, RTLinux…
Structure of a RTOS
Applications
RTOS-kernel
BSP
Custom-Hardware
"kernel" ?
The part of an operating system that provides the
most basic services to application software
running on a processor.
The "kernel" of a real-time operating system
("RTOS") provides an "abstraction layer" that
hides from application software the hardware
details of the processor (or set of processors)
upon which the application software will run.
Components of RTOS
The most important component of RTOS is its
kernel (Monolithic & Microkernel).
BSP or Board Support Package makes an RTOS
target-specific (It’s a processor specific code onto (processor) which we like to
have our RTOS running).
RTOS KERNEL
Task Management:
This set of services allows application software developers to design their software
as a number of separate "chunks" of software
-- each handling a distinct topic, a distinct goal, and perhaps its own real-time
deadline.
Each separate "chunk" of software is called a "task.“
Services in this category include the ability to launch tasks and assign priorities to
them.
The main RTOS service in this category is the scheduling of tasks as the embedded
system is in operation.
The Task Scheduler controls the execution of application software tasks, and can
make them run in a very timely and responsive fashion.
Intertask Communication and Synchronization:
These services make it possible for tasks to pass information from one
to another, without danger of that information ever being damaged.
They also make it possible for tasks to coordinate, so that they can
productively cooperate with one another.
Without the help of these RTOS services, tasks might well communicate
corrupted information or otherwise interfere with each other.
Timers:
Many embedded systems have stringent timing requirements
Most RTOS kernels also provide some basic Timer services,
such as task delays and time-outs.
Dynamic Memory Allocation:
Many (but not all) RTOS kernels provide Dynamic Memory Allocation
services.
This category of services allows tasks to "borrow" chunks of RAM
memory for temporary use in application software.
Often these chunks of memory are then passed from task to task, as a
means of quickly communicating large amounts of data between tasks.
Some very small RTOS kernels that are intended for tightly memory-
limited environments, do not offer Dynamic Memory Allocation
services.
Device I/O Supervisor:
Many (but not all) RTOS kernels also provide a "Device I/O Supervisor"
category of services.
These services, if available, provide a uniform framework for organizing
and accessing the many hardware device drivers that are typical of an
embedded system.
In addition to kernel services, many RTOSs offer a number of optional
add-on operating system components for such high-level services as
file system organization,
network communication,
network management,
database management,
user-interface graphics, etc.
Each of these add-on components is included in an embedded system
only if its services are needed for implementing the embedded
application, in order to keep program memory consumption to a
minimum.
RTOSs vs. general-purpose operating systems
Real-time operating systems is the need for " deterministic " timing
behaviour in the real-time operating systems.
Formally, "deterministic" timing means that operating system services
consume only known and expected amounts of time.
General-computing non-real-time operating systems are often quite non-
deterministic.
Their services can inject random delays into application software and thus
cause slow responsiveness of an application at unexpected times.
Task scheduling
Most RTOSs do their scheduling of tasks using a scheme called
"priority-based preemptive scheduling.“
Each task in a software application must be assigned a priority, with higher
priority values representing the need for quicker responsiveness.
Very quick responsiveness is made possible by the "preemptive" nature of
the task scheduling.
"Preemptive" means that the scheduler is allowed to stop any task at any
point in its execution, if it determines that another task needs to run
immediately.
The basic rule that governs priority-based preemptive scheduling is
that at every moment in time, "The Highest Priority Task that is Ready
to Run, will be the Task that Must be Running.“
In other words, if both a low-priority task and a higher-priority task are
ready to run, the scheduler will allow the higher-priority task to run
first.
The low-priority task will only get to run after the higher-priority task
has finished with its current work.
Each time the priority-based preemptive scheduler is alerted by an
external world trigger (such as a switch closing) or a software trigger
(such as a message arrival),
it must go through the following 5 steps:
• Determine whether the currently running task should continue to
run.
• If not ? Determine which task should run next.
• Save the environment of the task that was stopped (so it can continue
later).
• Set up the running environment of the task that will run next.
• Allow this task to run.
These 5 steps together are called "task switching."
Intertask communication and synchronization
RTOSs, offer a variety of mechanisms for communication and
synchronization between tasks.
These mechanisms are necessary in a pre-emptive environment of
many tasks.
Without them the tasks might well communicate corrupted
information or otherwise interfere with each other.
The most popular kind of communication between tasks in embedded
systems is the passing of data from one task to another.
Most RTOSs offer a message passing mechanism
• Most RTOSs offer a semaphore or mutex mechanism for handling
negative synchronization (sometimes called "mutual exclusion").
• These mechanisms allow tasks to lock certain embedded system
resources for their use only, and subsequently to unlock the resource
when they're done.
• For positive synchronization, different RTOSs offer different
mechanisms. Some RTOSs offer event-flags, while others offer signals.
Determinism and high-speed message passing
