Real-time systems

PREPARED BY: SUPERVISED BY:

Rawan Wael Hamdi DR. Howida Youssry

1
 Outline
o Definition : system
classic representation of RTS
o Definition : Response Time
o Definition : Real - Time system
o Definition : Failed System
o Definition : Embedded System
o Degrees of “ Real-Time”
Soft, Hard, and Firm “Real - Time”
where do deadlines come from?
o Definition : Real-Time Punctuality
o Real-Time Features in Mobile App Development
o Researches

2 2
 Definition: System

A system is mapping a set of inputs into a system of

outputs.

• A system is an assembly of components connected in an organized way.

• A system is fundamentally altered if a component joins or leaves it.
• It has a purpose.
• It has a degree of permanence(lastingness ).
• It has been defined as being of interest.
3
 Example: AReal-TimeControlSystem

o Inputs are excitations and outputs are corresponding

responses.
o Inputs and outputs may be digital or analog.
o Inputs are associated with sensors, cameras, etc.
o outputs with actuators, displays, etc.

4
 Classic/typical Representation of RTS

• A sequence of jobs to be scheduled and performance to be

predicted.
• Ignores the usual fact that the input source and hardware
under control maybe highly complex.

5
 Definition: ResponseTime

The time between the presentation of set of inputs

to a system and the realization of the required
behavior, including the availability of all associated
outputs, is called the response time of the system.

• How fast and punctual does it need to be ?

• Depends on the specific real - time system ..

• But what is a real – time system ?

6
 Definition: Real-Time System

A real-time system is a computer system that must

satisfy bounded response-time constrains or risk
severe consequences, including failure.

A real-time system is one whose logical correctness

is based on BOTH the correctness of the outputs
AND their timeliness.

7
 Definition: FailedSystem

A failed system is a system that cannot satisfy one or

more of the requirements stipulated in the system
requirements specifications.

Hence, rigorous specification of the system operating

criteria, including timing constraints, is necessary.

8
 Definition: EmbeddedSystem

An Embedded system is a system containing one or

more computers (or processors) having a central role
in the functionality of the system, but the system is
not explicitly called a computer.

• A real-time system may be embedded or non-embedded.

• But it is always reactive ..

• That is; task scheduling is driven by ongoing interaction

with the environment .
9
 ”Degreesof“Real-Time

All practical systems are ultimately real-time system;

• Even a batch-oriented system – for example, grade processing at

the end of a semester - is areal time.

• Although the system may have a response times of days, it must

respond within a certain time.

• Even a word-processing program should respond to commends

within a reasonable amount of time.

• Most of the literature refers to such systems as soft real-time

10 systems.
 ”Soft,HardandFirm"Real-Time

Definition: Soft Real-Time System

A soft real-time system is one in which performance is
degraded but not destroyed by failure to meet response-
time constraints.

Definition: Hard Real-Time System

A hard real-time system is one in which failure to meet
even a single deadline may lead to complete or
catastrophic system failure.

Definition: Firm Real-Time System

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 or catastrophic system
11
failure.
 Example: Real–Time Classification

12
 ?WhereDoDeadlinesComefrom

• Deadlines are based on the underlying physical phenomena

of the system under control.

• Punctuality is another measure related to response times ..

• Particularly important in periodically sampled systems
with high sampling rates (e.g., in audio and video signal
processing).

13
 Definition: Real-Time punctuality

14
 ?Example: whereaResponseTimeComesfrom

15
 DoorReopening Example(Cont’d)

16
 Real-Time Features in Mobile App Development

• Real-time features are nowadays necessary for a

successful mobile app.

• Real-Time technology almost swept the vast majority

of apps that need to provide real-time information to
consumers.

17
 Real-Time Features in Mobile App Development (cont’d)

• By definition, real-time features are capabilities to reflect the

changes in data in real-time without any lag time or delay.
• In the context of mobile apps, real-time features allow tracking the
location of a delivery agent or a rental car, get push notification
messages, get live order status, watch live streaming of contents, get
contents in the news feed, all in real-time.

• If we look at the present-day scenario, companies are now focusing

on integrating real-time features in their applications to achieve a
high level of digitalization.

18
 Researches
• Android and Real-Time Applications: Take Care!
Authors : Luc Perneel, Hasan Fayyad-Kazan, Martin Timmerman , Belgium
Year: 2014
• Using Mobile Cloud Computing for Real-Time Online Applications
Authors : Dominik Meil¨ander1 and Sergei Gorlatch, University of Muenster,
German
Year : 2015
• Reliable Real-Time Applications on Android OS
Authors : Bhupinder S. Mongia, Vijay K. Madisetti, Georgia Tech, Atlanta
Year : 2017
• Real-Time Transaction Management in Mobile Computing Systems
Authors : Ersan Kayan, O¨ zgu¨r Ulusoy, Turkey

19
 Android and Real-Time Applications: Take
Care!
• Showed whether Android in its current state can be qualified
to be used in real-time environments or not.
• Beagle Board-XM Rev C hardware is used as experimental
platform.
• Its characteristics are: based on the Texas Instruments DM3730 Digital Media
Processor, ARM Cortex A8 processor running at 1GHz, L1 instruction and data
caches are 32KB each, L2 cache is 64KB, and 512MB RAM at 166MHz.
• In this paper, we test latency and services performance metrics.
1. Tracing overhead
2. Clock tick processing duration
3. Thread switch latency between threads of same priority
4. Interrupt latency
5. Maximum sustained interrupt frequency
6. Semaphore acquire-release timings in the contention case
7. Mutex Locking behavior

20
 Experimental Results
Testing Results showed that Android in its current state
cannot be qualified to be used in real-time environments.

This is because of the Bionic C library which does not

implement the features and behavior that are mandatory
to have a real-time System, Also the semaphore
implementation behaves badly.
• The main aim of using a semaphore is process
synchronization and access control for a common
resource in a concurrent environment.

21
 ReliableReal-TimeApplicationson AndroidOS

Reliability considerations require a detailed evaluation of the

ability of the system to meet specifications (deadlines and
time constraints).
Architecture :
An Android system is a stack of software components. At the
bottom of the stack is Linux (kernel version 2.6)
• Provide process and memory management and security.
• Kernel handles all the things such as network interface and device drivers
On top of Linux is a set of libraries, including bionic (the
Google libc), media support for audio and video, graphics
(OpenGL ES), support for browsers (Webkit), and a lightweight
database, SQLite.

22
 ReliableReal-TimeApplicationson AndroidOS

We have chosen Texas Instruments' “Zoom II Mobile Development Kit”,

featuring TI's OMAP 3430 processor as the experimental platform.
The OMAP 3430 has an ARM core, which is the most popular core for
low power, hand-held general purpose micro-controllers.

23
 Experimental Results

The analysis of the experimental behavior of Android

under varying scenarios(deadlines, load)

A. Frequency of slippages increase with increasing load

B. Increasing frequency of interrupts increased slippage times
C. Increasing frequency of interrupts causes slippage

24
 Experimental Results

• Deadline misses of between 1 and 5 ms are common when the

frequency of interrupts is small (e.g., 10Hz).

• However, when the frequency of interrupts is increased (e.g., 1Khz),

deadline misses or response times in the order of 0.5sec are
observable. Furthermore, the frequency of these misses increases with
time through the process of slippage accumulation, resulting in
potentially a slowdown in the operation of the system.

• If there are more than a dozen interrupts per second under load, we
observe that the Android OS may not demonstrate reliable behavior
(e.g., response times increase significantly) with respect to real-time
constraints.
25
 Real-Time Transaction Management
in Mobile Computing Systems
• Recent advances in wireless communication networks and
portable computers have led to the emergence of mobile
computing systems, in which users with laptops, palmtops, and
notebook computers can access to a large number of shared
databases.
• In order to respond to real-time data access requirements of the
underlying applications, mobile computing systems need to be
supported by real-time DBMSs.
• We constructed a mobile transaction execution model and
implemented it on simulation program to evaluate the system
performance with different execution strategies.
• It was observed in the experiments that low-power CPU of the
mobile hosts and low-bandwidth wireless links are the bottlenecks
26
of the system.
 Performance Results

• These values were chosen to

have a System with high resource
utilization at all fixed hosts.

• The performance metric used for

the evaluations is Success Ratio;
i.e., the fraction of transactions
that satisfy their deadlines.

27
 Performance Results

• In the first experiment Increasing the number of

mobile hosts corresponds to an increase in the
total system load.
• As it can be seen from the figure, the
performance of the system degrades for both
strategies ESMH and ESFH as the transaction
load increases, and for all ranges of the
transaction load ESFH performs better than
ESMH.
• The reasons for the decrease in the
performance with both execution strategies are
the increasing load on the physical resources
and the increasing number of data conflicts.

28
 Thanks 

29