Hard and Soft Real Time Systems

Real Time System Hard and Soft Real Time Systems (Operational Definition)

A system is said to be Real Time if it is Hard Real Time System Hard Real Time System
required to complete it’s work & deliver  Failure to meet deadlines is fatal  Validation by provably correct procedures or
example : Flight Control System extensive simulation that the system always meets
it’s services on time.


Soft Real Time System the timings constraints

Example – Flight Control System  Late completion of jobs is undesirable but not Soft Real Time System
fatal.
 All tasks in that system must execute on  Demonstration of jobs meeting some statistical
 System performance degrades as more & more constraints suffices.
time. jobs miss deadlines
Non Example – PC system  Online Databases Example – Multimedia System
Qualitative Definition.  25 frames per second on an average

Misconception of RTOS Features of RTOS’s General RTOS Architecture

RTOS must be fast Multitasking and Preemptibility
The responsiveness of an RTOS depends Task Priority
on its deterministic behavior and not on Reliable and Sufficient Inter Task
its processing speed. Communication Mechanism
The ability of RTOS to response to events Priority Scheduling
within a timeline does not imply it is fast. Interrupt Handling
Resource Allocation
Kernel Broad categories of Kernel Monolithic kernel
An operating system generally consists Monolithic kernel Eg : Linux
of two parts: kernel space (kernel Microkernel Windows
mode) and user space (user mode). Exokernel
Kernel is
The smallest and central component of
an operating system

Microkernel Exokernel
It runs only services protecting the
AmigaOS and resources (i.e. tracking the ownership,
An RTOS generally avoids implementing the
guarding the usage, revoking kernel as a large monolithic program. The
QNX access to resources, etc) by providing low-level interface for library operating
systems and leaving the
kernel is developed instead as a micro-kernel
management to the application. with added configurable functionalities.
This implementation gives resulting benefit in
increase system configurability, as each
embedded application requires a specific set
of system services with respect to its
characteristics.
 Task Management
The kernel of an RTOS provides an Task management allows programmers A task object is defined by the following
abstraction layer between the to design their software as a number of set of components:
application software and hardware. separate “chunks” of codes with each • Task Control block (Task data structures
This abstraction layer comprises of six handling a distinct goal and deadline. residing in RAM and only accessible by RTOS)
main types of common services This service encompasses mechanism • Task Stack (Data defined in program residing
provided by the kernel to the in RAM and accessible by stack pointer)
such as scheduler and dispatcher that
application software • Task Routine (Program code residing in ROM)
creates and maintain task objects

Task Categories Why we need scheduling ?!

Periodic (time-triggered) Each computation (task) we want to execute needs resources
In real-time context, task is the basic 
resources: processor, memory segments, communication, I/O
unit of execution and is governed by  Aperiodic (event-triggered) devices etc.)
three time-critical properties; release  Static The computation must be executed in particular order (relative
to each other and/or relative to time)
time, deadline and execution time.  Dynamic The possible ordering is either completely or statistically a priori
Multi-Tasking System known (described)
scheduling: assignment of processor to computations;
 Preemptive: higher-priority process taking allocation: assignment of other resources to computations;
control of the processor from a lower-
priority
 Non-Preemptive : Each task can control the
CPU for as long as it needs it.
Real-time Scheduling Real-Time Scheduling
Taxonomy Scheduling Periodic Tasks Algorithms
Job (Jij): Unit of work, scheduled and executed by system.  In hard real-time systems, set of tasks are known apriori
Jobs repeated at regular or semi-regular intervals modeled as  Task Ti is a series of periodic Jobs Jij. Each task has the following
periodic parameters
Task (Ti): Set of related jobs.  ti - period, minimum interrelease interval between jobs in Task Ti.

 ci - maximum execution time for jobs in task Ti.

Jobs scheduled and allocated resources based on a set of Fixed Priority Algorithms Dynamic Priority Algorithms Hybrid algorithms
 rij - release time of the j
th Job in Task i (J in T ).
scheduling algorithms and access control protocols. ij i
 i - phase of Task Ti, equal to ri1.
Scheduler: Module implementing scheduling algorithms
 ui - utilization of Task Ti = ci / ti
Schedule: assignment of all jobs to available processors, Rate Deadline Earliest Maximum
 In addition the following parameters apply to a set of tasks Least
produced by scheduler. Monotonic
scheduling
Monotonic
scheduling
Deadline
First
Laxity First
Urgency
First
 H - Hyperperiod = Least Common Multiple of pi for all i:
Valid schedule: All jobs meet their deadline
 U - Total utilization = Sum over all ui.

 Schedulable utilization of an algorithm Us

 If U < Us the set of tasks can be guaranteed to be scheduled

Scheduling Algorithm
Scheduling Algorithm Static vs. Dynamic Scheduling Algorithm
Static vs. Dynamic Preemptive vs. Nonpreemptive

 Static Scheduling: Dynamic Scheduling: Preemptive Scheduling:

 All scheduling decisions at compile time.  All scheduling decisions at run time.  Event driven.
 Based upon set of ready tasks.  Each event causes interruption of running
 Temporal task structure fixed.
 Mutual exclusion and synchronization enforced tasks.
 Precedence and mutual exclusion satisfied by by explicit synchronization constructs.  Choice of running tasks reconsidered after each
the schedule (implicit synchronization).
 Benefits interruption.
 One solution is sufficient.  Flexibility.  Benefits:
 Any solution is a sufficient schedulability test.  Only actually used resources are claimed.  Can minimize response time to events.
 Benefits  Disadvantages  Disadvantages:
 Simplicity  Guarantees difficult to support  Requires considerable computational resources
 Computational resources required for for scheduling
scheduling
Rate Monotonic scheduling Rate Monotonic scheduling RM example
Simplest type of real time scheduling Priority assignment based on rates of tasks Process Execution Time Period
Higher rate task assigned higher priority
- Tasks are periodic, with hard deadlines P1 1 8
Schedulable utilization = 0.693
- Tasks are completely independent and do not P2 2 5
communicate with each other P3 2 10

- Tasks are scheduled according to priority and Where Ci is the computation time, and Ti is the release
period
task priorities are fixed
- Computation time is known and constant

If U < 0.693, schedulability is guaranteed

Tasks may be schedulable even if U > 0.693

Deadline Monotonic
scheduling
The utilization will be: Priority assignment based on relative
deadlines of tasks
The theoretical limit for processes, under which we Shorter the relative deadline, higher the
can conclude that the system is schedulable is priority

Since the system is schedulable!

Earliest Deadline First (EDF) Two Periodic Tasks
Dynamic Priority Scheduling Execution profile of two periodic tasks
 Process A
Priorities are assigned according to deadlines:
 Arrives 0 20 40 …
 Earlier deadline, higher priority  Execution Time 10 10 10 …
 Later deadline, lower priority  End by 20 40 60 …
 Process B
The first and the most effectively widely used
 Arrives 0 50 100 …
dynamic priority-driven scheduling algorithm.
 Execution Time 25 25 25 …
Effective for both preemptive and non-preemptive
 End by 50 100 150 …
scheduling.
Question: Is there enough time for the execution of two periodic
tasks?

Exercise :Five Periodic Tasks Least Laxity First Scheduling Algorithms in RTOS

Execution profile of five periodic tasks It assigns priority based on the slack Clock Driven Scheduling
time of a process.
Slack time is the amount of Weighted Round Robin Scheduling
time left after a job if the job was
started now.
Priority Scheduling
Its most common use is in embedded
systems, especially those with multiple (Greedy / List / Event Driven)
processors
Scheduling Algorithms in RTOS (contd) Scheduling Algorithms in RTOS (contd) Scheduling Algorithms in RTOS (contd)

Clock Driven Weighted Round Robin Priority Scheduling

 All parameters about jobs (release time/  Jobs scheduled in FIFO manner (Greedy/List/Event Driven)
execution time/deadline) known in  Time quantum given to jobs is proportional to it’s  Processor never left idle when there are
weight ready tasks
advance.
 Example use : High speed switching network
 Schedule can be computed offline or at  Processor allocated to processes according
 QOS guarantee.
some regular time instances. to priorities
 Not suitable for precedence constrained jobs.
 Minimal runtime overhead.  Job A can run only after Job B. No point in giving time
 Priorities
quantum to Job B before Job A.  static - at design time
 Not suitable for many applications.  Dynamic - at runtime

Priority Scheduling Resource Allocation in RTOS Solutions to Priority Inversion

Earliest Deadline First (EDF) Resource Allocation Non Blocking Critical Section
 Process with earliest deadline given highest  The issues with scheduling applicable here.  Higher priority Thread may get blocked by
unrelated low priority thread
priority  Resources can be allocated in
 Weighted Round Robin Priority Ceiling
Least Slack Time First (LSF)  Each resource has an assigned priority
 Priority Based
 slack = relative deadline – execution left  Priority of thread is the highest of all priorities of
Some resources are non preemptible
the resources it’s holding
Rate Monotonic Scheduling (RMS)  Example : semaphores
 For periodic tasks
Priority Inheritance
Priority Inversion if priority scheduling is used  The thread holding a resource inherits the priority
 Tasks priority inversely proportional to it’s period of the thread blocked on that resource
Other RTOS issues Linux for Real Time Applications Interrupt Handling in Linux
Interrupt Latency should be very small Scheduling Interrupts are disabled in ISR/critical
 Kernel has to respond to real time events  Priority Driven Approach sections of the kernel
 Interrupts should be disabled for minimum  Optimize average case response time
possible time  Interactive Processes Given Highest Priority No worst case bound on interrupt
For embedded applications Kernel Size should  Aim to reduce response times of processes latency avaliable
be small  Real Time Processes  eg: Disk Drivers may disable interrupt for
 Processes with high priority few hundred milliseconds
 Should fit in ROM
 No notion of deadlines
Sophisticated features can be removed Resource Allocation Not suitable for Real Time Applications
 No Virtual Memory  Interrupts may be missed
 No support for handling priority inversion
 No Protection

Why Linux RTLinux RTLinux (contd)

Coexistence of Real Time Applications Real Time Kernel at the lowest level Real Time Tasks
with non Real Time Ones Linux Kernel is a low priority thread  Statically allocate memory
 Example http server  Executed only when no real time tasks  No address space protection
Device Driver Base Interrupts trapped by the Real Time Non Real Time Tasks are developed in
Kernel and passed onto Linux Kernel Linux
Stability
 Software emulation to hardware interrupts Communication
 Interrupts are queued by RTLinux  Queues
 Software emulation to disable_interrupt()  Shared memory
 RTLinux Framework rtker – Our RTOS Pluggable Scheduler
Motivation Scheduler - part of the Application
 Our own OS
 Full grasp over source code – Easily modifiable, portable Kernel interacts with the scheduler
Features through an API
 Modular Design Application developer needs to
 Isolation of Architecture/CPU dependent and
independent code – Easy to Port implement the scheduler API
 Pluggable Scheduler  Can optimize on Data Structures &
 Two level Interrupt Handling
Algorithms for implementing the scheduler
 Small footprint
 Oskit’s Device Driver Framework

rtker – Block Diagram Two Level Interrupt Handling Other Features

Two level Interrupt Handling Footprint
 Top Half Interrupt Handler  Small footprint (~50kb)
 Called Immediately – Kernel never disables interrupts
 Cannot invoke thread library functions - Race Conditions Oskit’s Device Driver Framework
 Bottom Half Interrupt Handler  Allows direct porting of existing drivers
 Invoked when kernel not in Critical Section from Linux.
 Can invoke thread library functions
 Example – Ethernet Driver of Linux
Very Low Response time (as compared to
Linux)
Other RTOS’s Other RTOS’s (contd) Peripheral devices and protocols
LynxOS VxWorks • Interfacing
 Microkernel Architecture Serial/parallel ports, USB, I2C, PCMCIA, IDE
 Monolithic Architecture
 Kernel provides scheduling/interrupt handling • Communication
 Additional features through Kernel Plug Ins(KPIs)
 Real Time Posix compliant Serial, Ethernet, Low bandwidth radio, IrDA,
 TCP/IP stack , Filesystem  Cross development System 802.11b based devices
 KPI’s are multithreaded • User Interface
pSOS LCD, Keyboard, Touch sensors, Sound, Digital
 Memory Protection/ Demand Paging Optional
 Development and Deployment on the same host
 Object Oriented OS pads, Webcams
 OS support for compilers/debuggers
• Sensors
A variety of sensors using fire, temperature,
pressure, water level, seismic, sound, vision

TASK WITH RTOS – WORKING EXAMPLE TO DO

Worst-Case Execution Time What is the “Execution Time”
Say you have a robot that is exploring an area.
The computer controlling the robot has a number of tasks to do: Analysis of a program?
getting sensor input, driving the wheels, and running a navigational
program that may have a fairly high computational load. Characteristics of Real-Time
One key issue in such an environment is to ensure that all the tasks are
done in a timely way. Systems
On a microcontroller you might use a timer to generate interrupts that • Concurrent control of separate
regularly address the motors and sensors while having the navigational
system components
task running as the main program. But that fairly simple model breaks
down in a number of situations. • Constrained resources
• Guaranteed response times
For example, what if the navigational program is actually a collection of • Often have to be extremely
programs each of which need to run at different intervals for different dependable
durations (perhaps image processing, routing, and mapping programs)? It
• Interaction with special purpose
would be quite possible to write code to handle this, but having libraries
(or an OS) which provides APIs for scheduling would be very helpful. A hardware
real-time operating system (RTOS) provides tools that allow us to
schedule these tasks. - CAN DO BY FreeRTOS , VX Works.
 62

Hard Real-Time Systems

The Timing Problem

Probability
 Schedulability analysis must be performed
Unsafe: Safe Worst Case  Hence, it is essential that an upper bound on the execution times of all tasks is
Best Case Execution Time Execution Time
Execution Time Measurement Estimate known
Exact Worst Case  Commonly called the Worst-Case Execution Time (WCET)
Execution Time

 Controllers in planes, cars, plants, … are expected to finish their tasks within
reliable time bounds.
Execution Time

Why may we care about the WCET?

Worst case executime time And why may we care about the
BCET? Best Case execution time Measuring WCET/BCET
Execution time may depend on program inputs
• perform schedulability anaylsis • In this case, quality of measurements depends on judicious
• ensure meeting deadlines • benchmark hardware choice of
• assess resource needs for real-time systems • assess code quality inputs
• WCET accuracy may be safety-critical! • assess resource needs for non/soft real-time • Execution time may depend on execution context
systems (cache content, state of pipeline, ...)
• ensure meeting livelines (new starting points) • Typically need to add safety margin to best/worst result
measured
• Extensive testing/measurement still common
practice
 Analysing WCET/BCET Flow Analysis
Instead of measuring execution times, compute Analyse dynamic behaviour of program
Flow analysis
them • Number of loop iterations, Recursion depth, Input
• Advantages dependences, Infeasible paths, Function instances, ...
• Can ensure safety of result • Get information from
• Saves testing effort Static Analysis
• Disadvantages Manual Annotation
• Try to be as tight as possible—may not always
succeed • Analysis level
• Typically requires extensive analysis effort Object code
•Source code (may need non-trivial mapping to object code)
• Accuracy depends on
• Complexity of hardware
• Program structure
• Quality of hardware model

Mapping !!!
Cont….
The set of structurally possible flows for a program, i.e. those given by the
structure of the program, is usually infinite, since e.g. loops can be taken an
arbitrary number of times

• The executions are made finite by bounding all loops with some upper limit
on the number of executions (basic finiteness)

• Adding even more information, e. g. about the input data, allows the set of Loop bounds: Easy to find in this example; in general, very
difficult to
executions to be narrowed down further, to a set of statically allowed paths. determine
This is the “optimal” outcome of the flow analysis. • Infeasible paths: Can we exclude a path, based on data
analysis?
A-B-C-E-F-G is infeasible—since if x>5, it is not possible that x *
2 < 0.
Well, really? What about integer overflows? Must be sure that
these do not
happen in the example...
Flow Info Graph
 Mapping Problem exists!!!

Provides bounds on the number of times different program parts may be

Embedded compilers often do a lot of code optimizations executed

- Valid for all possible executions

- Important to fit code and data into limited memory resources
- Optimizations may significantly change code (and data) layout - Examples of provided info:
- After optimizations flow info may no longer be valid " Bounds of loop iterations
" Bounds on recursion depth
" Infeasible paths
Solutions:
- Use special compiler also mapping flow info (not common) - Info provided by:
- Use compiler debug info for mapping (only works with little/no " Static program analysis
optimizations) " Manual annotations
- Perform flow analysis on binaries (most common)
 Cont.

Low-Level Analysis
 Low-Level Analysis
Global Low-Level Analysis
• Considers execution time effects of machine features that reach across
entire program

• Instruction/data caches, branch predictors, translation lookaside buffers

(TLBs)

Local Low-Level Analysis

• Considers machine features that affect single instruction & its neighbours
• Scalar/superscalar pipelines
Local Low-Level Analysis - Local Low-Level Analysis -
Pipelining Pipelining

MODULE-2 EMBEDDED SYSTEMS (ES)

Real Time Operating  Embedded system = Hardware + Software

Systems

Tradeoffs for  Software as well as hardware plays an

RTOS equal role in embedded system

 For specific application or specific part of a

POSIX larger system
 OPERATING SYSTEM (OS) GPOS vs RTOS RTOS - FEATURES
 An operating system (OS) is a software used to  Multitasking and Preemptibility:
 Determinism: RTOS predict the output of the
provide an interface between the hardware and  An RTOS must be multi-tasked and pre-emptible to
system for a given input
support multiple tasks in real-time applications.
user for managing & sharing the resources of the
system  Hardware architecture: RTOS are light weight
OS which are used in small architecture  Task Priority:
 In RTOS, preemption capability is achieved by
 OS perform basic tasks, such as:  Kernel: RTOS will use pre-emptive kernel assigning individual task with the appropriate priority
 Recognizing input from keyboard level.
 Sending output to the display screen  Scheduling: RTOS scheduling algorithm is based
 Keeping track of files on priority  Inter Task Communication Mechanism:
 Managing communication with other peripheral
 Interrupt latency: Interrupt latency of the RTOS  For multiple tasks to communicate in a timely
manner and to ensure data integrity among each
 Every general-purpose computer must have an is always zero other, reliable and sufficient inter-task communication
operating system to run other programs and synchronization mechanisms are required.

RTOS - FEATURES RTOS - FEATURES

 Priority Inheritance:  Predefined Short Latencies:
 To allow applications with stringent priority
requirements to be implemented, RTOS must have a  Task switching latency: The time needed to save the
sufficient number of priority levels when using context of a currently executing task and switching to
priority scheduling. another task is desirable to be short.

 Interrupt latency: The time elapsed between execution

 Control of Memory Management: of the last instruction of the interrupted task and the
 To ensure predictable response to an interrupt, an first instruction in the interrupt handler.
RTOS should provide way for task to lock its code
and data into real memory.
 Interrupt dispatch latency. The time from the last
instruction in the interrupt handler to the next task
scheduled to run.
 RTOS - MISCONCEPTIONS RTOS - ARCHITECTURE
 The architecture of an RTOS is dependent on the
 RTOS should be fast: Not true. An RTOS should have
a deterministic behavior in terms of deadlines but its not complexity of its deployment.
true that the processing speed of an RTOS is fast.
 Good RTOSs are scalable to meet different sets
 RTOS written in Assembly coding: Real-time of requirements for different applications.
programming is not written completely using assembly
coding  For simple applications, an RTOS usually
comprises only a kernel.
 All RTOS are same: No, it differs based on meeting a
deadline Hard, firm and soft.  For more complex embedded systems, an RTOS
can be a combination of various modules,
 RTOS cause CPU overhead: Again this is not true. including the kernel, networking protocol stacks,
Only 1%-4% of CPU time is required by an RTOS.
and other components.

RTOS - ARCHITECTURE RTOS - ARCHITECTURE RTOS - ARCHITECTURE

Applications

RTOS
BSP

Hardware

BASIC BUILDING COMPONENTS OF RTOS Structure of RTOS RTOS - Architecture

 RTOS - ARCHITECTURE RTOS - ARCHITECTURE RTOS - ARCHITECTURE
 Kernel is the smallest and central component of  An RTOS generally avoids implementing the  Microkernel architecture majorly caters to the
an operating system. kernel as a large monolithic program. problem of ever growing size of kernel code
which we could not control in the monolithic
 Its services include managing memory and approach.
devices and also to provide an interface for  The kernel is developed instead as a micro-
software applications to use the resources. kernel with added configurable functionalities.  This architecture allows some basic services like
 Additional services such as managing protection device driver management, protocol stack, file
of programs and multitasking may be included  This implementation gives resulting benefit in system etc to run in user space.
depending on architecture of operating system. increase system configurability, as each
embedded application requires a specific set of  This reduces the kernel code size and also increases
 There are three categories of kernel models system services with respect to its characteristics. the security and stability of OS as we have the
available: Monolithic, Micro and Hybrid kernel bare minimum code running in kernel.

RTOS - ARCHITECTURE RTOS - ARCHITECTURE RTOS - ARCHITECTURE

 So, if suppose a basic service like network  So, what the bare minimum that microkernel
 Some suppliers also provide a root file
service crashes due to buffer overflow, then architecture recommends in kernel space? system, a toolchain for building programs to
only the networking service's memory would  Managing memory protection run on the embedded system, and utilities
be corrupted, leaving the rest of the system still  Process scheduling to configure the device (while running)
functional.  Inter Process communication (IPC) along with the BSP.

 In this architecture, all the basic OS services  Apart from the above, all other basic services can
 Many RTOS providers provide template
which are made part of user space are made to be made part of user space and can be run in the
form of servers.
BSP's, developer assistance, and test suites to
run as servers which are used by other
aid BSP developers in bringing up the RTOS
programs in the system through inter process QNX, Nucleus, VxWorks follows the Microkernel approach on a new hardware platform.
communication (IPC).
 RTOS – KERNEL SERVICES RTOS – KERNEL SERVICES
Task Management
Task Management
 During the execution of an application program,
individual tasks are continuously changing from one  In RTOS each task may exist in any one of the
state to another. following states,
 Dormant : Task doesn’t require computer time
 However, only one task is in the running mode (i.e.
given CPU control) at any point of the execution.  Ready: Task is ready to go active state, waiting
processor time
 In the process where CPU control is change from
one task to another, context of the to-be-suspended  Active: Task is running
task will be saved while context of the to-be-
executed task will be retrieved. This process is called  Suspended: Task put on hold temporarily
context switching.
 Pending: Task waiting for resource

RTOS – KERNEL SERVICES RTOS – KERNEL SERVICES RTOS – KERNEL SERVICES

Task Management Task Management Task Synchronization
 Dispatcher: The dispatcher gives control of the CPU  Task Synchronization & inter task communication
to the task selected by the scheduler by performing serves to enable information to be transmitted safely
context switching and changes the flow of from one task to another.
execution.  Synchronization is essential for tasks to share
 At any time an RTOS is running, the flow of mutually exclusive resources (devices, buffers, etc)
execution passes through one of three areas: and/or allow multiple concurrent tasks to be
executed.
through the task program code
 Task synchronization is achieved by two mechanisms:
through an interrupt service routine  Event objects are used when task synchronization is required
without resource sharing.
Task States in RTOS TCB in RTOS through the kernel.
 Semaphores is associated with resource count and a wait queue.
 RTOS – KERNEL SERVICES RTOS – KERNEL SERVICES RTOS – KERNEL SERVICES
Inter Task Communication Memory Management Memory Management
 Inter task communication involves sharing of data  An embedded RTOS usually strive to achieve small
among tasks through common memory space, footprint by including only the functionality needed  This allocation of memory is done using task-control
transmission of data, etc. for the user’s applications. block model and this set of memory is commonly
known as kernel stack and the management process
 Inter task communications is executed using following  Two types of memory managements are provided in
termed Stack Management.
mechanisms RTOS – Stack and Heap.
 Upon the completion of a program initialization,
 Message queue is an object through which task send or  In a multi-tasking RTOS, each task needs to be
physical memory of the MCU or MPU will usually be
receive messages placed in a shared memory. allocated with an amount of memory for storing
occupied with program code, program data and
their contexts (i.e. volatile information such as
 Pipes is an object that provide simple communication system stack. The remaining physical memory is
registers contents, program counter, etc) for context
channel used for unstructured data exchange among called heap.
switching.
tasks.

RTOS – KERNEL SERVICES RTOS – KERNEL SERVICES RTOS – KERNEL SERVICES

Memory Management Timer Management Interrupt and Event Handling
 This heap memory is typically used by the kernel for  In embedded systems, system and user tasks are often
 A fundamental challenge in RTOS design is
dynamic memory allocation of data space for tasks. scheduled to perform after a specified duration.
supporting interrupts and thereby allowing
asynchronous access to internal RTOS data structures.
 The memory is divided into fixed size memory  To provide such scheduling, there is a need for a
blocks, which can be requested by tasks. periodical interrupt to keep track of time delays and  The interrupt and event handling mechanism of an
timeout. This is taken care by Timer Management RTOS provides the following functions:
 When a task finishes using a memory block it must unit.  Defining interrupt handler
return it to the pool.  Creation and deletion of ISR
 Most RTOSs today offer both “relative timers” that  Referencing the state of an ISR

 This process of managing the heap memory is known work in units of ticks, and “absolute timers” that  Enabling and disabling of an interrupt
as Heap management. work with calendar date and time.  Changing and referencing of an interrupt mask
 RTOS – KERNEL SERVICES RTOS – KERNEL SERVICES
Interrupt and Event Handling Device I/O Management

 The interrupt and event handling mechanism of an  An RTOS kernel is often equipped with a device I/O
RTOS helps to ensure: management service to provide a uniform
 Data integrity by restricting interrupts from occurring framework (“API”) and supervision facility for an
when modifying a data structure embedded system to organize and access large
 Minimum interrupt latencies due to disabling of numbers of diverse hardware device drivers.
interrupts when RTOS is performing critical
operations
 However, most device driver APIs and supervisors
 Fastest possible interrupt responses that marked the are “standard” only within a specific RTOS.
preemptive performance of an RTOS
 Shortest possible interrupt completion time with
minimum overheads

SELECTION OF RTOS SELECTION OF RTOS SELECTION OF RTOS

 An RTOS is usually chosen based on its performance Technical Considerations Technical Considerations
or one’s comfort and familiarity with the product.
 Scalability:  Run-time facilities:
However, such a selection criteria is insufficient.
 Size or memory footprint is an important  Run-time facilities refer to the services of the
consideration. kernel (i.e. inter task communication, task
 There is a wide variety of RTOS ranging from  Most RTOS are scalable in which only the code synchronization, interrupts and events handling,
commercial RTOS, open-source RTOS to internally required is included in the final memory footprint. etc).
developed RTOS to choose from. Therefore, it is a
role of the programmers to exercise extra caution in  Portability:
 Often, a current application may outgrow the  Different application systems have different sets of
the selection process.
hardware it was originally designed for as the requirements.
requirements of the product increases.
 The selection criteria of RTOS can be broadly
 An RTOS with such a capability can therefore be  Comparison of RTOSs is frequently between the
classified into two main areas; technical features of ported between processor architectures and between kernel-level facilities they provided.
RTOS and commercial aspect of the implementation. specific target systems.
 SELECTION OF RTOS SELECTION OF RTOS SELECTION OF RTOS
Technical Considerations Technical Considerations Commercial Considerations
 Run-time performance:  Development tools:  Costs:
 A sufficient set of development tools including
 Run-time performance of an RTOS is generally debugger; compiler and performance profiler  Costs are a major consideration in selection of
governed by the interrupt latency, context might help in shortening the development and RTOS.
switching time and few other metric of kernel debugging time, and improve the reliability of the
performance. coding.  Some of the RTOS packages are complete
operating systems including not only the real-
 This consideration is useful if the performance  Commercial RTOSs usually have a complete set of time kernel but also an input/output manager,
tools for analyzing and optimizing the RTOSs’
assessment of the application on a given RTOS windowing systems, a file system, networking,
behavior whereas Open-Source RTOSs will not
is to prototype its performance-critical aspects language interface libraries, debuggers, and
have.
on standard hardware. cross platform compilers.

SELECTION OF RTOS SELECTION OF RTOS

Commercial Considerations Commercial Considerations
 License:  Supplier stability/ longevity:

 RTOS vendor usually has a few license models for  Development with RTOS is not a problem free
customers to choose from. process.
 A perpetual license enables customers to purchase the
development set and pay an annual maintenance fee,  Reliable and consistent support from supplier
which entitles he/her to upgrades and bug fixes. is a critical factor in ensuring the prompt
completion of a project.
 An alternative model known as subscription model
allow customers to “rent” the development set whilst  Supplier longevity thus helps to determine the
paying an annual fee to renew the access.
availability of support.
 RTOS – TRADEOFFS RTOS – TRADEOFFS RTOS – TRADEOFFS
“Better” RTOS vs “better” hardware Resources vs Cost
 It all starts with a product and its requirements.
What sort of device is your company building?  Using a more code-efficient RTOS and  To run application such-and-such, how much
application software may reduce the required memory would you need? How much memory
 As you know, embedded devices run on very
hardware or allow the same functionality to be will you have available?
simple to the very complex, from mass market
achieved on less expensive Microprocessors.
consumer applications like cell phones to single-
 What are the power requirements? What
shot devices like Mars landers. List of common
 Or, using more expensive hardware (i.e., 32-bit response time is required?
RTOS tradeoffs are,
microprocessor vs. 8-bit) may allow a less
 “Better” RTOS vs “better” hardware
expensive RTOS like Linux. That is, the  Is it a “hard” real-time device, such as a military
 Resources vs Cost
better/more expensive the RTOS the computer system or a medical device? Or is it a
 Commercial RTOS vs in-house RTOS
worse/cheaper the hardware can be and, to some consumer device that can tolerate less true real-
 Royalty Free vs. Per Device Royalty
extent, vice-versa. time performance?

RTOS – TRADEOFFS RTOS – TRADEOFFS RTOS – TRADEOFFS

Resources vs Cost Resources vs Cost Resources vs Cost
ITEM DESCRIPTION
ITEM DESCRIPTION
Hard vs. Software Real-time To what extent, must the device have hard
Power Is this a low power device? Will it run on batteries?
real-time capabilities?
How long does it need to run before a re-charge?
Durability/User Interaction To what extent will this device be “on its own”
Processor What sort of processor will the device have? 8-, 16-, 32-
– away from humans who can reset it? Is it a
bit? Which particular architecture? If the processor has
military or industrial device that will operate
already been chosen, this pre-limits the selection of
in a harsh temperature or vibration
available RTOSes.
environment?
Memory/Footprint How much and what type(s) of memory is available for Networking and/or Will the device be communicating, either over
the RTOS? How much additional is needed for Communications wires or wirelessly? If so, are there particular
applications? What are the trade-offs between the two? Constraints standards such as Zigbee, 802.11, or ethernet
that will be required?
 REAL-TIME POSIX REAL-TIME POSIX
POSIX.4b: Timeouts POSIX.4b: Timeouts

 In time-critical systems it is important to limit the  The services chosen are those that are most likely
maximum amount of time that a process can stay going to be used in time-critical code, and did not
waiting for one of these services to complete. already have timeout capability:

 POSIX.4b defines new versions of some of the

 Wait for a semaphore to become unlocked
blocking services with built-in timeouts.
 Wait for the arrival of a message to a message
 These timeouts specify the maximum amount of time queue
that the process may be suspended while waiting for  Send a message to a queue
the service to complete.  Wait for a mutex to become unlocked.

REAL-TIME POSIX REAL-TIME POSIX REAL-TIME POSIX

POSIX.4b: Execution time clocks POSIX.4b: Sporadic Server POSIX.4b: Interrupt Control
 Many real-time systems need the ability to capture
 An optional CPU-time clock is defined for each  A new scheduling policy is defined interrupts generated by special devices, and handle them
at the application program.
process and each thread. (SCHED_SPORADIC) that implements the sporadic
server scheduling algorithm.  The interfaces defined will not achieve complete
 The POSIX.4 clocks & timers interface is used to portability of the application programs due to the many
manage execution-time clocks.  This policy can be used to process aperiodic events at differences in interrupt handling for the different
architectures.
the desired priority level, allowing to guarantee the
 Execution time clocks allow to detect when an timing requirements of lower priority tasks.  However, application portability is enhanced by this
execution time overrun occurs, and to activate the interface, because a reference model is established and
appropriate error handling actions  The sporadic server gives fast response times and because non portable code is confined to specified
makes systems with aperiodic events predictable. modules, thus reducing the number of changes necessary
to port the application.
 REAL-TIME POSIX REAL-TIME POSIX REAL-TIME POSIX
POSIX.4b: I/O Device Control POSIX.13: REAL-TIME APPLICATION POSIX.13: REAL-TIME APPLICATION
 In real-time systems it is common to interact with the ENVIRONMENT PROFILES ENVIRONMENT PROFILES
environment through special devices such as digital or  The real-time application environment profiles (AEPs) 2) Real-time Controller: Corresponds to a special purpose
analog input/output devices, counters, etc. defined in POSIX.13 provide the adequate subsets of controller system. It is like the minimum real-time profile,
features of the base standards that are required for a but adding a file system and I/O terminal. Only one
 Typically, drivers for these special devices are written particular application environment. process but multiple threads are allowed.
by the application developer, and a standardized
operation for interfacing with these drivers allows  Four real-time AEPs are being defined in POSIX.13: 3) Dedicated System: Corresponds to a large embedded
the application operations calling that driver to be system with no file system. It has multiple processes and
well defined. 1) Minimum System: Corresponds to a small embedded threads.
system with no need for a memory management unit
 POSIX.4b defines a function that allows an (MMU), no file system (no disk), and no I/O terminal.
Only one process is allowed, but multiple threads can run 4) Multi-purpose System: Corresponds to a large real-time
application program to transfer control information
concurrently. system with all the features supported.
to and from a device driver

REAL-TIME POSIX
POSIX.13: REAL-TIME APPLICATION
ENVIRONMENT PROFILES

Characteristics of the Real-Time Profiles