UNIT- I BASIC REAL-TIME CONCEPTS:

Terminology
Systems Concepts
Software is traditionally divided into system programs and application programs.
System programs consist of software that interfaces with the underlying computer
hardware, such as schedulers, device drivers, dispatchers, and programs that act as tools for the
development of application programs. These tools include compilers, which translate high-order
language programs into assembly code; assemblers, which translate the assembly language into
a special binary format called object or machine code; and linkers, which prepare the object code
for execution. An operating system is a specialized collection of system programs that manage
the physical resources of the computer. As such, a real-time operating system is a systems
program.
Application programs are programs written to solve specific problems, such as payroll
preparation, inventory, and navigation. Certain design considerations play a role in the design of
certain systems programs and application software intended to run in real-time environments.
Definition: A system is a mapping of a set of inputs into a set of outputs.
Definition: The time between the presentation of a set of inputs to a system (stimulus)
and the realization of the required behavior (response), including the availability of all associated
outputs, is called the response time of the system.

Real-Time Definitions
Definition: A real-time system is a system that must satisfy explicit (bounded) response-
time constraints or risk severe consequences, including failure.
Definition: A failed system is a system that cannot satisfy one or more of the
requirements stipulated in the formal system specification.
Definition: A real-time system is one whose logical correctness is based on both the
correctness of the outputs and their timeliness.
When Is a System Real-Time?
Definition: A soft real-time system is one in which performance is degraded but not
destroyed by failure to meet response-time constraints.
Definition: A hard real-time system is one in which failure to meet a singledeadline may
lead to complete and catastrophic system failure.
 Definition: A firm real-time system is one in which a few missed deadlines will not lead to
total failure, but missing more than a few may lead to complete and catastrophic system failure.
Determinism
Definition: A system is deterministic if, for each possible state and each set of inputs, a
unique set of outputs and next state of the system can be determined.

Real-Time System Design Issues

1. The selection of hardware and software, and evaluation of the trade-off needed for a
cost-effective solution, including dealing with distributed computing systems and the
issues of parallelism and synchronization.
2. Specification and design of real-time systems and correct representation of temporal
behavior.
3. Understanding the nuances of the programming language(s) and the real-time
implications resulting from their translation into machine code.
4. Maximizing of system fault tolerance and reliability through careful design.
5. The design and administration of tests, and the selection of test and development
equipment.
6. Taking advantage of open systems technology and interoperability. An open system is an
extensible collection of independently written applications that cooperate to function as
an integrated system. For example, a number of versions of the open operating system,
Linux, have emerged for use in real-time applications. Interoperability can be measured
in terms of compliance with open system standards, such as the CORBA real-time
standard.
7. Finally, measuring and predicting response time and reducing it. Performing a
schedulability analysis, that is, determining and guaranteeing deadline satisfaction, a
priori, is the focus of most of scheduling theory.

Example Real-Time Systems

Write on your own

Common Misconceptions
1. Real-time systems are synonymous with “fast” systems.
2. Rate-monotonic analysis has solved “the real-time problem.”
3. There are universal, widely accepted methodologies for real-time systems specification
and design.
4. There is never a need to build a real-time operating system, because many commercial
products exist.
 5. The study of real-time systems is mostly about scheduling theory.

Brief History
Lol

Hard Vs Soft Real-Time Systems

The release time of a job is the instant of time at which the job becomes available for execution.
The job can be scheduled and executed at any time at or after its release time whenever its data
and control dependency conditions are met.
The deadline of a job is the instant of time by which its execution is required to be completed.

HARD REAL-TIME SYSTEMS

A Hard Real-Time System guarantees that critical tasks complete on time. This goal requires that
all delays in the system be bounded from the retrieval of the stored data to the time that it takes
the operating system to finish any request made of it.

SOFT REAL-TIME SYSTEMS

A Soft Real Time System where a critical real-time task gets priority over other tasks and retains
that priority until it completes. As in hard real time systems kernel delays need to be bounded.

A REFERENCE MODEL OF REAL TIME SYSTEMS

Processors and Resources
 We divide all the system resources into two major types: processors and resources.
 Sometimes, we will need to distinguish the types of processors. Two processors are of the
same type if they are functionally identical and can be used interchangeably.
 In our discussion, a “resource” almost always mean a reusable resource
 A resource is plentiful if no job is ever prevented from execution by the lack of this
resource. A resource that can be shared by an infinite number of jobs (e.g., a file that is
readable simultaneously by all) need not be explicitly modeled and hence never appears
in our model

Temporal Parameters of Real Time Work Load

The workload on processors consists of jobs, each of which is a unit of work to be allocated
processor time and other resources. A set of related jobs that execute to support a function of
the system is a task. We typically assume that many parameters of hard real-time jobs and tasks
are known at all times; otherwise, it would not be possible to ensure that the system meet its
hard real-time requirements. The number of tasks (or jobs) in the system is one such parameter.
Fixed, Jittered, and Sporadic Release Times
In many systems, we do not know exactly when each job will be released. In other words, we do
not know the actual release time ri of each job Ji; only that r i is in a range [ri − ,ri + ]. ri can be as
early as the earliest release time ri − and as late as the latest release time ri + . Indeed, some
models assume that only the range of ri is known and call this range the jitter in ri, or release-
time jitter
Almost every real-time system is required to respond to external events which occur at random
instants of time. When such an event occurs, the system executes a set of jobs in response. The
release times of these jobs are not known until the event triggering them occurs. These jobs are
called sporadic jobs or aperiodic jobs because they are released at random time instants.
Execution Time
Another temporal parameter of a job, Ji, is its execution time, ei. ei is the amount of time required
to complete the execution of Ji when it executes alone and has all the resources it requires.
Hence, the value of this parameter depends mainly on the complexity of the job and the speed
of the processor used to execute the job, not on how the job is scheduled.

Periodic Task Model

The periodic task model is a well-known deterministic workload model [LiLa]. With its various
extensions, the model characterizes accurately many traditional hard real-time applications, such
as digital control, real-time monitoring, and constant bit-rate voice/video transmission. Many
scheduling algorithms based on this model have good performance and well-understood
behavior. There are now methods and tools to support the design, analysis, and validation of
real-time systems that can be accurately characterized by the model. For these reasons, we want
to know it well and be able to use it proficiently.
Periods, Execution Times, and Phases of Periodic Tasks
In the periodic task model, each computation or data transmission that is executed repeatly at
regular or semi-regular time intervals in order to provide a function of the system on a continuing
basis is modeled as a period task. Specifically, each periodic task, denoted by Ti, is a sequence of
jobs. The period pi of the periodic task Ti is the minimum length of all time intervals between
release times of consecutive jobs in Ti. Its execution time is the maximum execution time of all
the jobs in it. With a slight abuse of the notation, we use e i to denote the execution time of the
periodic task Ti, as well as that of all the jobs in it. At all times, the period and execution time of
every periodic task in the system are known.

Precedence Constraints and Data Dependency

Data and control dependencies among jobs may constrain the order in which they can execute.
In classical scheduling theory, the jobs are said to have precedence constraints if they are
constrained to execute in some order. Otherwise, if the jobs can execute in any order, they are
said to be independent.

Functional Parameters
While scheduling and resource access-control decisions are made disregarding most functional
characteristics of jobs, several functional properties do affect these decisions. The work-load
model must explicitly describe these relevant properties, and this is done by the values of
functional parameters. Among them are pre-emptivity, criticality, optional interval, and laxity
type.

Preemptivity of Jobs
A job is preemptable if its execution can be suspended at any time to allow the execution of other
jobs and, later on, can be resumed from the point of suspension. Computation jobs that execute
on CPUs are examples of preemptable jobs. In nonreal-time systems, such jobs are typically
scheduled in a round-robin manner; this is possible because they are preemptable.

Criticality of Jobs
The importance (or criticality) of a job is a positive number that indicates how critical the job is
with respect to other jobs; the more critical the job, the larger its importance. the terms priority
and weight are often used to refer to importance; the more important a job, the higher its priority
or the larger its weight. We will use the terms priority and weight extensively later to mean
attributes that are unrelated to the importance.

Optional Executions
It is often possible to structure an application so that some jobs or portions of jobs are optional.
If an optional job or an optional portion of a job completes late or is not executed at all, the
system performance may degrade, but nevertheless function satisfactorily. In contrast, job and
portions of jobs that are not optional are mandatory; they must be executed to completion.
Therefore, during a transient overload when it is not possible to complete all the jobs in time, we
may choose to discard optional jobs (i.e, leave them unexecuted or partially executed) so that
the mandatory jobs can complete in time. In this way, the system can trade the quality of the
results it produces and the services it delivers for timeliness of its results and services.

Laxity Type and Laxity Function

The laxity type of a job indicates whether its timing constraints are soft or hard. As mentioned
earlier, in real-time systems literature, the laxity type of a job is sometimes supplemented by a
usefulness function. This function gives the usefulness of the result produced by the job as a
function of its tardiness.
Topics lite : Resource Parameters of Jobs and Parameters of resources, Typical Real Time.