REAL-TIME OPERATING SYSTEM

Dr. J.RANGARAJ
AP/ECE/GCT
Outline
Model of real-time systems
Architecture of real-time systems
Characteristics and function of Real-Time Systems
Application of Real-Time Systems
Real Time Programming Languages
Model of a Real time system
Architecture of RTOS
Characteristics of a RTOS
Time constrain
Every real-time task is associated with some
time constraints. One form of time constraints that
is very common is deadlines associated with tasks.
It is the responsibility of the real-time
operating system (RTOS) to ensure that all
tasks meet their respective time constraints.
New Correctness Criterion:

In real-time systems, correctness

implies not only logical correctness of the
results, but the time at which the results are
produced is important.

A logically correct result produced after the

deadline would be considered as an incorrect
result.
Safety-Criticality(Reliability):

A safe system is one that does not cause

any damage even when it fails.
A safety-critical system is required to be highly
reliable since any failure of the system can
cause extensive damages.
Concurrency:
A real-time system usually needs to
respond to several independent events
within very short and strict time bounds.
The real-time system must process
data from all the sensors concurrently,
otherwise signals may be lost and the system
may malfunction.
Task Criticality:

Task criticality is determined by examining

how critical are the results produced by the task to
the proper functioning of the system.
Further, in the event of a failure of
a highly critical task, immediate failure detection
and recovery are important.
However, it should be realized that task
priority is a different concept and task criticality
does not solely determine the task priority
Stability:
Under overload conditions, real-time
systems need to continue to meet the
deadlines of the most critical tasks, though
the deadlines of non-critical tasks may not be
met.
Scalability
Because RTOS can be used in a wide variety
of embedded systems, they must be able to
scale up or down to meet application-specific
requirements.
Depending on how much functionality is
required, an RTOS should be capable of
adding or deleting modular components,
including file systems and protocol stacks.
Predictability
Because many embedded systems are also real-
time systems, meeting time requirements is
key to ensuring proper operation.
The RTOS used in this case needs to be
predictable to a certain degree. The term
deterministic describes RTOS with predictable
behavior, in which the completion of operating
system calls occurs within known timeframes.
Function of RTOS
Task management
Scheduling
Resource allocation
Interrupt handling
Design challenges of RTOS

The selection of hardware , system software

and evaluation of the trade-off needed for a
competitive solution, including dealing with
distributed computing systems .
 Issues of concurrency and synchronization.
 Issues of Specification and design of real-
time .
Optimizing (with application-specific
objectives) of system fault tolerance and
reliability through careful design.
The design and administration of adequate tests at
different levels of hierarchy, and the selection of
appropriate development tools and test equipment.

Issues of understanding the nuances of the high-level

programming language(s) and the real-time
implications resulting from their optimized compilation
into machine-language code.

Finally, estimating and measuring response times and

(if needed) reducing them. Performing a schedulability
analysis, that is, determining and guar­anteeing
deadline satisfaction, a priori.
Priority inversion
 High-level task stalled due to low-level using shared
resources, then a medium-level task holding up the
low-level one
 Solution: Priority inheritance – give low-level task
high-level priority
 Mars Pathfinder had this problem
Deadlock (It is a situation(deadlock problem) when 2
processes sharing the same resources are effectively
preventing each other from accessing the resources)
 Solution: “Instant Inheritance” implementation of
Priority Ceiling Protocol – semaphores possibly needed
by higher processes become priority tokens

Task information
 Priorities for each task
 Worst-case runtime
 Best-case period
Application of RTOS
Different RTOS available
Vxworks
Windows CE
Symbian OS
RT Linux
Free RTOS
pSOS
eCos
Real Time Programming Languages
Assembly languages
C is most commonly used in RTOS programming
C++ and Ada is next more popular for large project.
Java/ Real time java may also be choice for some
application
Performance Metrics Measures

 Interrupt Latency: Ratio of the sum of latencies of the

tasks and Interrupt with respect to the sum of the
execution times.
 CPU load for how much time CPU not idle
 Worst-Case Execution time with respect to mean
execution time.
 Context switching time
 Throughput.
 Clock rate. Cache size and level, no of core, memory
Three types of tasks for finding performance

Scheduler must take into account (aperiodic, periodic and

sporadic) separately.
Worst Case Execution Time (WCET)
(Prediction of Execution Time)
 Worst case execution time is typically used in reliable
real-time systems, where understanding the worst case
timing behaviour of software is important for reliability or
correct functional behaviour.
 WCET analysis usually refers to the execution time of single
thread, task or process.
 The predicted WCETs can be used to determine an
appropriate scheduling scheme for the tasks and to perform
an overall schedulability analysis in order to guarantee that
all timing constraints will be met (also called timing
validation).
 Some real-time operating systems offer tools for
schedulability analysis, but all these tools require the
WCETs of tasks as input.
Static analysis techniques
A static WCET tool attempts to estimate WCET by
examining the computer software without executing it
directly on the hardware
Static analysis tools work at a high-level to determine
the structure of a program's task, working either on a
piece of source code or disassembled binary executable.
They also work at a low-level, using timing information
about the real hardware that the task will execute on,
with all its specific features.
By combining those two kinds of analysis, the tool
attempts to give an upper bound on the time required
to execute a given task on a given hardware platform.
Prediction of the WCET by
Static Program Analysis
 CFG Building decodes, i.e. identifies instructions, and reconstructs the control-
flow graph (CFG) from a binary program.

 CRL FILE(certificate revocation list) : Enables security administrators to block

untrusted entities

 Value Analysis computes value ranges for registers and address ranges for
instructions accessing memory.

 Loop Bound Analysis determines upper bounds for the number of iterations of
simple loops.

 Cache Analysis classifies memory references as cache misses or hits.

 Pipeline Analysis predicts the behavior of the program on the processor

pipeline.

 Path Analysis : In path analysis ,Integer linear programming(ILP) is used to

determines a worst-case execution path of the program
Worst Case Execution Time (WCET) estimation
through Abstract Interpretation in the presence of
Data Caches
Existing Art for WCET (with Data cache)
Linear algebra based
− Cache Miss Equations
− Presburger Arithmetic
Abstract Interpretation based − MUST analysis
Data flow based − Static cache simulation
Simulation based
 Four Subproblems
Address analysis - Abstract Interpretation
Cache analysis − Abstract Interpretation
Access Sequencing − Partial unrolling (physical
and
virtual)
Worst case Path Analysis- Integer linear
programming(ILP)
Subproblem 1: Address Analysis
Objective : To compute a safe approximation of the set of memory locations that
can be accessed by any memory reference(call memory space into region)
A special case of general executable analysis.

EX: Detecting malicious content, Algorithm learning, Code comparison, Timing

analysis.

Issues in this analysis:

Absence of type information(Binary machine code does not have data type
(integer, char, float) info at compiler level. At register level we can have data
types

Difficult to separate address generation and data computations

Compiler transformations might have changed apparent source code structure

Abstract Interpretation
Define − Operations on the elements of
abstract domain must be consistent with the
concrete execution semantics(instruction by
instruction )
Subproblem 2: Cache Analysis
Objective − To compute a lower bound on the
number of cache hits
It is an extension of the Abstract Cache
model and Must Analysis technique
Cache Must-Analysis:
Tracks the set of memory blocks definitely
residing in the cache at any program point
Useful for tracking memory accesses that will
always result in cache hits regardless of
program input
Subproblem 3: Access Sequencing
Objective : Determine frequency and ordering
of accesses to distinct memory locations
(referenced during execution)
Overview:
-Sets of memory addresses do not incorporate
reuse and conflict information − {x,y}
represents accesses x,x,x,y and x,y,x,y and not
any other representation accesses
-Idea is to unroll loops partially − Both physical
and virtual unrolling
-
Subproblem 4: Worst case Path Analysis
To compute the overall worst case path in the
program and the associated cost
After the worst case execution costs for each
basic block has been individually computed,
an approximation of the overall worst case
cost and corresponding path is obtained by
solving an ILP
Micro-architectural modeling
Dynamically variable instruction execution time due to::
Cache,
Pipeline
Speculative execution (branch prediction)