Real-Time Systems

Rawan wael hamdi

FCI Fayoum, Academic Master, CS
Supervised by: Dr. Howida Youssry

Abstract
Growing global connectivity, changing consumer demands for always-available data,
and always-on, sensor-enabled enterprise environments are driving the creation,
collection, and analysis of exponential amounts of data. By 2025, we estimates that
there will be 79.41 zettabytes of data created and nearly 30 percent of it will require
real-time processing enabled by real-time systems.

The need for real-time processing is especially crucial for businesses in robotics,
manufacturing, healthcare, and high-precision industries, such as oil and gas and
power that rely on real-time data for continuous improvement in safety, efficiency, and
reliability.

One key factor in ensuring data is processed in real-time for businesses in these types
of industries is a system’s ability to prioritize, manage, and execute real-time workloads
over non-real-time workloads.

For example, modern automotive manufacturers are highly reliant on robots to work
together on a production line to assemble a car. The robots will pass each other parts,
drill or weld, or perform safety inspections—all of which require a high level of precision
and meticulous timing. In this use case, a real-time system must have the ability to
not only process data in a defined, predictable time frame but also ensure that critical
tasks, such as safety-related workloads, are completed prior to less critical tasks.

Introduction
A system is defined as being real-time if it is required to respond to input stimuli within
a finite and specified time interval. The stimuli being either an event at the interface
to the system or some internal clock tick that is, at least notionally, coordinated with
the passage of time in the system’s environment.
Real-Time system refers to any information processing system with hardware and
software components that perform real-time application functions and can respond to
events within predictable and specific time constraints. Common examples of real-time
systems include air traffic control systems, process control systems, and autonomous
driving systems.

In some systems the required response times are measured in milliseconds, in others
it is seconds or even minutes. Nevertheless they all have dead-lines that must be
satisfied.
Real-time systems are systems where timeliness is essential to correctness. In a real-
time system the correctness of the system depends not only the logical results of the
computations, but also on the physical instant at which these results are produced.
Consider the airbag in a car. It does not suffice to establish that after a collision it will
expand it is also crucial that this happens neither too early nor too late. Such systems
play a major role in industrial design and development.
In particular embedded systems, whose primary purpose is to offer some service other
than computation itself, outnumber full grown processors by an order of magnitude,
most computations today are done on small, weak, and cheap hardware.
These systems are found in everyday use and range from simple appliances like
wristwatches and remote controls to complex designs, such as mobile phones, cars,
and airplanes.

What Is a 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.

 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.

Types of real-time systems based on timing constraints:

1. Soft real-time systems

A soft real-time system is one in which performance is degraded but not

destroyed by failure to meet response-time constraints.

2. Hard real-time systems

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

3. Firm real-time systems

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 failure.
 Example for clarification :

Terms related to real-time system:

1. Job: A job is a small piece of work that can be assigned to a processor and
may or may not require resources.
2. Task: A set of related jobs that jointly provide some system functionality.
3. Release time of a job: It is the time at which the job becomes ready for
execution.
4. Execution time of a job: It is the time taken by the job to finish its
execution.
5. Deadline of a job: It is the time by which a job should finish its execution.
6. Response time of a job: 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.

Real-time features are nowadays necessary for a successful mobile

app.
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.
Android and Real Time applications

Android is considered today as one of the leading platforms for mobile devices. Being
as an open source platform distinguishes it from most other mobile platforms such
iOS, Blackberry and Windows Phone.
Android is an open source platform built by Google that includes an operating system,
middleware, and applications for mobile platforms. It is based on Linux kernel that
enables developers to write applications primarily in Java with support for C/C++ as
well.

Android is finding widespread acceptance in the mobile and portable computing

market, and this study examines, test the real time behavior and performance of
Android, in order to make it clear whether Android can be advised to be used in open
real time environments.

ANDROID ARCHITECTURE

An Android system is a stack of

software components. At the bottom
of the stack is Linux (kernel version
2.6). This provides basic system
functionality like process and memory
management and security. Also, the
kernel handles all the things such as
network interface and a vast array of
device drivers, which make it easy to
interface to peripheral hardware.
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.
Alongside the libraries, on top of the OS, is the Android runtime “Dalvik Virtual
Machine” (DVM) which is a key component of an Android system. DVM makes full use
of Linux for memory management and multi-threading, which is needed to support the
Java language.
Above the libraries and Android-runtime layer, is the Application Framework layer
which provides many higher-level services to applications in the form of Java classes.
The use of it will vary from one implementation to another.
The top layer is the application layer which contains a number of applications that
are routinely distributed with Android, which may include email, SMS, calendar,
contacts, and Web browser.
Experimental Setup

1. In the First Research

We have chosen Texas Instruments' “Zoom II Mobile Development Kit”, hardware is
used as our experimental platform.
Its characteristics are: 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.

2. In the Second Research

Beagle Board-XM Rev C hardware is used as our 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.

Experimental and Test Procedure

The real-time responsiveness or latency measurement on Android is broken down in
two parts.
The first part is the latency introduced in handling of an interrupt within the Linux
kernel i.e., the time it takes for the Linux kernel, after receiving an interrupt (timer
interrupt in our experiment), to propagate this event to the event management layer
in the kernel.
The second part is the latency introduced by Dalvik VM, i.e., the time difference
between when it receives the event from the kernel event management layer and
passes it up to the Application running on top of the VM.

Another factor that has to be taken into account for deciding whether the system is
reliable for real-time use, in addition to the latency incurred in handling of external
events, is the “variation” in this latency i.e., for a system to be deemed reliable for
real-time application, there has to be an upper bound on how much variation in the
latency can be tolerated by the real-time application. We have analyzed our
experimental measurements with these criteria in mind.
In the First Research

This experiment involves system level latency measurements i.e., the delays
introduced by the Linux kernel and the Dalvik virtual machine combined, in
propagating the event (timer) up to the Java application running on top of Android.
To achieve this purpose, two separate applications, Test and Loading, were
developed on the Android Zoom II MDK.
The Test application’s task was to schedule a Timer Task which would run after the
expiry of fixed timer interval (i.e., 10ms or 1ms in this experiment) and observe the
error (slippage in deadline) by noting the time difference between when the task was
scheduled from the Java application, and when the actual timer events were
received. The application stores this slippage values onto a file which was read back
for later analysis.

The Loading application’s task was to exercise the CPU and other I/O resources on
the system so that measurements could be taken under varying loads.
The Loading application schedules another Timer Task with a varying timer interval
(10 ms for normal load and 1 ms for heavy load).

The Test application was tested in three scenarios:

(1) Test application alone, or “no load”
(2) Test application with loading application with 10ms timer scheduler interval
Simulating “normal load”
(3) Test application with Loading application with 1ms timer scheduler interval,
simulating “heavy load”. The Test application itself was run with a) 100 ms timer
interval, and, b) 1 ms timer interval.

EXPERIMENTAL RESULTS

The analysis of the experimental behavior of Android under varying scenarios

(deadlines, load).
A. Frequency of slippages increase with increasing load
In all cases, increasing the load caused the frequency of slippage to increase. For
instance, in Fig. 3, the slippage times occurred less frequently than in Fig. 4 (under
Heavy Load).
B. Increasing frequency of interrupts increased slippage times
As shown in Fig. 4 & 7, when interrupts are infrequent the slippage times were small
(i.e., 1ms). However, when the frequency of interrupts was increased, as in Fig. 7,
the slippage times increased to around 80ms.
C. Increasing frequency of interrupts causes slippage accumulation
As noticed in Fig. 6 & 7, a frequent interrupt caused Android keep accumulating
missed deadlines, and fall further back, with more frequent misses in meeting
deadlines, which is exacerbated by a heavy load.
In the Second Research
We test latency and services performance metrics based on experimental
measurements such as thread switch latency, interrupt latency, sustained interrupt
frequency, and finally the behavior of mutex and semaphore.

EXPERIMENTAL RESULTS

Our 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.
Conclusion

Android was not meant to be used in real-time applications. It is a Java executable

platform consuming as less power as possible for handheld devices with an attractive
Graphical User Interface. Of course, one cannot avoid that some people try to use it
in a real-time context based on its popularity only.

Our experimental results and analyses show that deadline misses of between 1 and
5 ms are common when the frequency of interrupts is small (e.g., 10 Hz). However,
when the frequency of interrupts is increased (e.g., 1 KHz), 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.

References

1. M. R. Lyu, Handbook of Software Reliability Engineering, McGraw Hill

Publishing, 1995, ISBN 0-07-039400-8.
2. J. Musa, “Operational Profiles in Software-Reliability Engineering, IEEE
Software, March 1993.
3. C. Maia, L. M. Nogueira and L. M. Pinho, “Evaluating Android OS for
Embedded Real-Time Systems,” in Proceedings of the 6th International
Workshop on Operating Systems Platforms for Embedded Real-Time
Applications, Brussels, Belgium, 2010.
4. Google, “Android,” [Online]. Available: www.android.com.
5. K. Tapas Kumar and P. Kolin, “Android on Mobile Devices: An Energy
Perspective,” in 2010 IEEE 10th International Conference on Computer and
Information Technology (CIT), 2010.