INTRODUCTION - RTOS

Real-time operating systems (RTOS) are used in environments where a large number of
events, mostly external to the computer system, must be accepted and processed in a short
time or within certain deadlines. such applications are industrial control, telephone switching
equipment, flight control, and real-time simulations. With an RTOS, the processing time is
measured in tenths of seconds. This system is time-bound and has a fixed deadline. The
processing in this type of system must occur within the specified constraints. Otherwise, This
will lead to system failure.

Examples of real-time operating systems are airline traffic control systems, Command
Control Systems, airline reservation systems, Heart pacemakers, Network Multimedia
Systems, robots, etc.
The real-time operating systems can be of 3 types –

RTOS

1. Hard Real-Time Operating System: These operating systems guarantee that critical
tasks are completed within a range of time.

For example, a robot is hired to weld a car body. If the robot welds too early or too
late, the car cannot be sold, so it is a hard real-time system that requires complete car
welding by the robot hardly on time., scientific experiments, medical imaging
systems, industrial control systems, weapon systems, robots, air traffic control
systems, etc.

2. Soft real-time operating system: This operating system provides some relaxation in
the time limit.

For example – Multimedia systems, digital audio systems, etc. Explicit, programmer-
defined, and controlled processes are encountered in real-time systems. A separate
process is changed by handling a single external event. The process is activated upon
the occurrence of the related event signaled by an interrupt.

Multitasking operation is accomplished by scheduling processes for execution

independently of each other. Each process is assigned a certain level of priority that
 corresponds to the relative importance of the event that it services. The processor is
allocated to the highest-priority processes. This type of schedule, called, priority-
based preemptive scheduling is used by real-time systems.

3. Firm Real-time Operating System: RTOS of this type have to follow deadlines as
well. In spite of its small impact, missing a deadline can have unintended
consequences, including a reduction in the quality of the product. Example:
Multimedia applications.

4. Deterministic Real-time operating System: Consistency is the main key in this type
of real-time operating system. It ensures that all the task and processes execute with
predictable timing all the time,which make it more suitable for applications in which
timing accuracy is very important. Examples: INTEGRITY, PikeOS.

Advantages:

The advantages of real-time operating systems are as follows-

1. Maximum consumption: Maximum utilization of devices and systems. Thus more

output from all the resources.

2. Task Shifting: Time assigned for shifting tasks in these systems is very less. For
example, in older systems, it takes about 10 microseconds. Shifting one task to
another and in the latest systems, it takes 3 microseconds.

3. Focus On Application: Focus on running applications and less importance to

applications that are in the queue.

4. Real-Time Operating System In Embedded System: Since the size of programs is

small, RTOS can also be embedded systems like in transport and others.

5. Error Free: These types of systems are error-free.

6. Memory Allocation: Memory allocation is best managed in these types of systems.

Disadvantages:
The disadvantages of real-time operating systems are as follows-

1. Limited Tasks: Very few tasks run simultaneously, and their concentration is very
less on few applications to avoid errors.
 2. Use Heavy System Resources: Sometimes the system resources are not so good and
they are expensive as well.

3. Complex Algorithms : The algorithms are very complex and difficult for the designer
to write on.

4. Device Driver And Interrupt signals: It needs specific device drivers and interrupts
signals to respond earliest to interrupts.

5. Thread Priority: It is not good to set thread priority as these systems are very less
prone to switching tasks.

6. Minimum Switching: RTOS performs minimal task switching.

2. Applications of Real-time System:

Real-time System has applications in various fields of the technology.

1. Industrial application:
Real-time system has a vast and prominent role in modern industries. Systems are made real
time based so that maximum and accurate output can be obtained. In order to such things real
-time systems are used in maximum industrial organizations. These system somehow lead to
the better performance and high productivity in less time. Some of the examples of industrial
applications are: Automated Car Assembly Plant, Chemical Plant etc.
2. Medical Science application:
In the field of medical science, real-time system has a huge impact on the human health and
treatment. Due to the introduction of real-time system in medical science, many lives are
saved and treatment of complex diseases has been turned down to easier ways. People
specially related to medical, now feel more relaxed due to these systems. Some of the
examples of medical science applications are: Robot, MRI Scan, Radiation therapy etc.
3. Peripheral Equipment applications:
Real-time system has made the printing of large banners and such things very easier. Once
these systems came into use, the technology world became more strong. Peripheral
equipment are used for various purposes. These systems are embedded with micro chips and
perform accurately in order to get the desired response. Some of the examples of peripheral
equipment applications are: Laser printer, fax machine, digital camera etc.
4. Telecommunication applications:
Real-time system map the world in such a way that it can be connected within a short time.
Real-time systems have enabled the whole world to connect via a medium across internet.
These systems make the people connect with each other in no time and feel the real
environment of togetherness. Some examples of telecommunication applications of real-time
systems are: Video Conferencing, Cellular system etc.
5. Defense applications:
In the new era of atomic world, defense is able to produce the missiles which have the
dangerous powers and have the great destroying ability. All these systems are real-time
system and it provides the system to attack and also a system to defend. Some of the
applications of defense using real time systems are: Missile guidance system, anti-missile
system, Satellite missile system etc.

6. Aerospace applications:
The most powerful use of real time system is in aerospace applications. Basically hard real
time systems are used in aerospace applications. Here the delay of even some nano second is
not allowed and if it happens, system fails. Some of the applications of real-time systems in
aerospace are: Satellite tracking system, Avionics, Flight simulation etc.

Basic Model of a Real-Time System

Basic Model of a Real-time System: The basic model of a real-time system presents the
overview of all the components involved in a real-time system. Real-time system includes
various hardware and software embedded in a such a way that the specific tasks can be
performed in the time constraints allowed. The accuracy and correctness involved in real-
time system makes the model complex. There are various models of real-time system which
are more complex and are hard to understand. Here we will discuss a basic model of real-time
system which has some commonly used terms and hardware. Following diagram represents a
basic model of Real-time System:

Sensor: Sensor is used for the conversion of some physical events or characteristics into the
electrical signals. These are hardware devices that takes the input from environment and
gives to the system by converting it. For example, a thermometer takes the temperature as
physical characteristic and then converts it into electrical signals for the system.

Actuator: Actuator is the reverse device of sensor. Where sensor converts the physical
events into electrical signals, actuator does the reverse. It converts the electrical signals into
the physical events or characteristics. It takes the input from the output interface of the
system. The output from the actuator may be in any form of physical action. Some of the
commonly used actuator are motors and heaters.

Signal Conditioning Unit: When the sensor converts the physical actions into electrical
signals, then computer can’t used them directly. Hence, after the conversion of physical
actions into electrical signals, there is need of conditioning. Similarly while giving the output
when electrical signals are sent to the actuator, then also conditioning is required. Therefore,
Signal conditioning is of two types:

 Input Conditioning Unit: It is used for conditioning the electrical signals coming
from sensor.
 Output Conditioning Unit: It is used for conditioning the electrical signals coming
from the system.

Interface Unit: Interface units are basically used for the conversion of digital to analog and
vice-versa. Signals coming from the input conditioning unit are analog and the system does
the operations on digital signals only, then the interface unit is used to change the analog
signals to digital signals. Similarly, while transmitting the signals to output conditioning unit
the interface of signals are changed i.e. from digital to analog. On this basis, Interface unit is
also of two types:

 Input Interface: It is used for conversion of analog signals to digital.

 Output Interface: It is used for conversion of digital signals to analog.

The basic model of a real-time system consists of the following three major components −

The Operating Environment

The operating environment of a real-time system is the world external to the system from
where input signals are received. The operating environment of a real time system is modeled
as a collection of input events that occur over time.

The Controlled System

The controlled system of a real-time system is typically a computing unit that can process
input signals received from the operating environment to produce the output signals. It
composed of several hardware and software components that perform processing of input
signals-based instructions.

The Feedback System

The feedback system of a real-time system is a system of hardware and software

components, allowing the system to respond the variations in the inputs and outputs in real-
time manner. It consists of two major parts; one is feedback controller and another is
feedback mechanism.

The feedback mechanism monitors the variations in the output of the system and compare it
with a reference signal. If there is a difference between the sampled signal and reference
signal, then a corrective action is taken by the feedback controller to bring the output signal
to its desired level.

CHARACTERISTICS OF REAL-TIME SYSTEM:

Following are the some of the characteristics of Real-time System:

1. Time Constraints: Time constraints related with real-time systems simply means that
time interval allotted for the response of the ongoing program. This deadline means
that the task should be completed within this time interval. Real-time system is
responsible for the completion of all tasks within their time intervals.
2. Correctness: Correctness is one of the prominent part of real-time systems. Real-time
systems produce correct result within the given time interval. If the result is not
obtained within the given time interval then also result is not considered correct. In
real-time systems, correctness of result is to obtain correct result in time constraint.
3. Embedded: All the real-time systems are embedded now-a-days. Embedded system
means that combination of hardware and software designed for a specific purpose.
Real-time systems collect the data from the environment and passes to other
components of the system for processing.
4. Safety: Safety is necessary for any system but real-time systems provide critical
safety. Real-time systems also can perform for a long time without failures. It also
recovers very soon when failure occurs in the system and it does not cause any harm
to the data and information.
5. Concurrency: Real-time systems are concurrent that means it can respond to a
several number of processes at a time. There are several different tasks going on
within the system and it responds accordingly to every task in short intervals. This
makes the real-time systems concurrent systems.
6. Distributed: In various real-time systems, all the components of the systems are
connected in a distributed way. The real-time systems are connected in such a way
that different components are at different geographical locations. Thus all the
operations of real-time systems are operated in distributed ways.
7. Stability: Even when the load is very heavy, real-time systems respond in the time
constraint i.e. real-time systems does not delay the result of tasks even when there are
several task going on a same time. This brings the stability in real-time systems.
8. Fault tolerance: Real-time systems must be designed to tolerate and recover from
faults or errors. The system should be able to detect errors and recover from them
without affecting the system’s performance or output.
9. Determinism: Real-time systems must exhibit deterministic behavior, which means
that the system’s behavior must be predictable and repeatable for a given input. The
system must always produce the same output for a given input, regardless of the load
or other factors.
10. Real-time communication: Real-time systems often require real-time
communication between different components or devices. The system must ensure
that communication is reliable, fast, and secure.
11. Resource management: Real-time systems must manage their resources efficiently,
including processing power, memory, and input/output devices. The system must
ensure that resources are used optimally to meet the time constraints and produce
correct results.
12. Heterogeneous environment: Real-time systems may operate in a heterogeneous
environment, where different components or devices have different characteristics or
capabilities. The system must be designed to handle these differences and ensure that
all components work together seamlessly.
13. Scalability: Real-time systems must be scalable, which means that the system must
be able to handle varying workloads and increase or decrease its resources as needed.
14. Security: Real-time systems may handle sensitive data or operate in critical
environments, which makes security a crucial aspect. The system must ensure that
data is protected and access is restricted to authorized users only.
RTOS - Task scheduling
Most RTOSs do their scheduling of tasks using a scheme called priority-based pre-emptive
scheduling . Each task in a software application must be assigned a priority, with higher
priority values representing the need for quicker responsiveness. Very quick responsiveness
is made possible by the preemptive nature of the task scheduling. Preemptive means that the
scheduler is allowed to stop any task at any point in its execution, if it determines that another
task needs to run immediately. The basic rule that governs priority-based preemptive
scheduling is that at every moment in time, “The highest priority task that is ready to run will
be the task that must be running.” In other words, if both a low-priority task and a high-
priority task are ready to run, the scheduler will allow the high-priority task to run first. The
low-priority task will only get to run after the high-priority task has finished with its current
work.

What if a low-priority task has already begun to run, and then a higher-priority task becomes
ready? This might occur because of an external world trigger such as a switch closing. A
priority-based preemptive scheduler will behave as follows: It will allow the low-priority task
to complete the current assembly-language instruction that it is executing. (But it won't allow
it to complete an entire line of high-level language code; nor will it allow it to continue
running until the next clock tick.) It will then immediately stop the execution of the low-
priority task, and allow the higher-priority task to run. After the higher-priority task has
finished its current work, the low-priority task will be allowed to continue running. (Figure 2)

Figure 2. Timeline for priority-based preemptive scheduling example

Of course, while the higher-priority task is running, an even higher-priority task might
become ready. In that case, the running task would be preempted (stopped temporarily) to
allow the even-higher-priority task to run. When this task has finished its current work, the
pre-empted task would be allowed to continue. And thus in this case, both higher-priority
tasks would complete their work before a low-priority task would be allowed to continue
running. This scenario might be called nested preemption .
Each time the priority-based preemptive scheduler is alerted by an external world trigger
(such as a switch closing) or a software trigger (such as a message arrival), it must go through
the following 5 steps:

 Determine whether the currently running task should continue to run. If not…
 Determine which task should run next.
 Save the environment of the task that was stopped (so it can continue later).
 Set up the running environment of the task that will run next.
 Allow this task to run.

These 5 steps together are called task switching .

Fixed-time task switching

The time it takes to do task switching is of interest when evaluating an operating system. A
simple general-computing (non-preemptive) operating system might do task switching only at
timer tick times, which might for example be ten milliseconds apart. Then if the need for a
task switch arises anywhere within a 10-millisecond timeframe, the actual task switch would
occur only at the end of the current 10-millisecond period. Such a delay would be
unacceptable in most real-time embedded systems.

In more sophisticated pre-emptive task schedulers, the scheduler may need to search through
arrays of tasks to determine which task should be made to run next. If there are more tasks to
search through, the search will take longer. Such searches are often done by general-
computing operating systems, thus making them non-deterministic. Real-time operating
systems, on the other hand, avoid such searches by using incrementally updated tables that
allow the task scheduler to identify the task that should run next in a rapid fixed-time fashion.

For a general-computing (non-real-time) operating system, the task switching time generally
rises as a software system includes more tasks that can be scheduled (Figure 3). However, the
actual time for a task switch is not the time shown by the dashed sloping line. Instead, in any
given task switch instance, it might be well above or well below the time shown by the
dashed sloping line. The shaded regions surrounding the dashed sloping line simply show the
likelihood of the actual task switch time being that far above or below the dashed sloping
line.
 Figure 3. Switching time vs. number of tasks for real-time and non-real-time systems

On the other hand, the horizontal solid line shows the task switching time characteristic of a
real-time operating system. It is constant, independent of any load factor such as the number
of tasks in a software system.

Note that in some instances, such as the leftmost area of the graph, the task switching time
might in special cases be quicker for a general-computing non-real-time operating system,
than for a real-time operating system. This does not detract from the appropriateness of a
real-time operating system for real-time embedded applications. For, in fact, the term real-
time does not mean “as fast as possible.” Rather, real-time demands consistent, repeatable,
known timing performance. Although a non-real-time operating system might do some faster
task switching for small numbers of tasks, it might equally well introduce a long time delay
the next time it does the same task switch. The strength of a real-time operating system is in
its known, repeatable timing performance, which is also typically faster than that of a non-
deterministic task scheduler in situations of large numbers of tasks in a soft-ware system.
Most often, the real-time operating system will exhibit task-switching times much faster than
its non-real-time competitor when the number of tasks grows above 5 or 10.

SAFETY AND RELIABILITY

Safety and reliability are often equated, especially with respect to software, but there is a
growing trend to separate the two concepts. Reliability is usually defined as the probability
that a system will perform its intended function for a specified period of time under a set of
specified environmental conditions, Safety is the probability that conditions which can lead to
an accident (hazards) do not occur whether the intended function is performed or not.

Another way of saying this is that software safety involves ensuring that the software will
execute within a system context without resulting in unacceptable risk.

In general, reliability requirements are concerned with making a system failure- free whereas
safety requirements are concerned with making it accident-free. These are not usually
synonymous. There are many failures of differing consequences that are possible in any
complex system.

The consequences may range from minor annoyance up to death or injury. Reliability is
concerned with every possible software fault whereas safety is only concerned with those
which result in actual system hazards. That is, hazard is not equivalent to failure; hazards
involve the risk of loss or harm whereas failures may not. Not all software faults cause safety
problems and not all software which functions according to specification is safe. Severe
accidents have occurred while something was operating exactly as intended-i.e., without
failure.

The need to separate safety and reliability results from the fact that different techniques may
be used to enhance the two qualities, and even more important, these two qualities are often
conflicting. Increasing safety may, in some circumstances, actually decrease reliability.

Real-time software is a special class of software with some unique characteristics. The most
important is that often the inputs are not fixed in time or forseeable; the timing is determined
by the real world and not by the programmer. This implies that we cannot anticipate a priori
all possible conditions with which the software may have to deal. Another important
characteristic is that normally such systems are distributed among different processors, each
controlling different real-world processes which potentially interact. Synchronization of
different processors and/or different software processes on the same processor is a difficult
problem; conceptual tools must be developed that make the modeling of real-time process
intercommunication easy to analyze and to implement. Real-time systems normally also have
rigorous time constraints that introduce' one more dimension in the problem of verify 'cation
of these systems; to verify the correctness of the functional aspects is not sufficient.

The above characteristics require the use of specially tailored techniques and tools for the
design and verification of real-time software. And when very high standards for safety and
reliability are required, extreme care must be devoted to the design and verification of the
software throughout its entire life-cycle.

The concept of fault-tolerance is important for safe and reliable systems design. Hardware
fault-tolerance is usually implemented through functional and hardware redundancy. To
detect hardware failures, identical programs are executed on redundant hardware with
majority voting on the results or on a single hardware system with self-test and standby
switching to spares. The latter may conflict with the real-time requirements and not be
practical for some systems. An attempt has been made to apply these hardware techniques to
software. However, the potential benefits of using multiple versions of the software will be
decreased by common mode failures of the software.

There is recent experimental evidence to indicate that in dependent development of software

does not guarantee the absence of correlated failures of the different program versions.
Testing real-time software presents special problems. It is impossible to predict all the
possible input situations or all the possible sequences of input events when external interrupts
are a feature of the system. Furthermore, even if such tests were possible, the interpretation of
the output results may be difficult. For these reasons, analytic techniques are essential to
erify the correctness of real-time software. A number of models exist for modeling the
software. Petri nets seem to be receiving much attention and several papers included in this
issue involve modeling of real-time systems with Petri nets.

Programming languages for real-time software also deserve special attention. Using real-time
languages which include special features for implementing the timing-critical aspects of the
application along with features to improve safety and reliability can enhance the quality of
the resulting code .