RTSS 4

Real-time Embedded Software Systems: An Introduction S. Agrawal & P.
Bhatt
Technology Review #2001-04
Real-time
Embedded
Software Systems
An Introduction
Sandeep Agrawal
Pankaj Bhatt
August 2001
Real-time Embedded Software Systems: An Introduction S. Agrawal & P. Bhatt
© Copyright 2001 Tata Consultancy Services. All rights reserved
No part of this document may be reproduced or distributed in any form by any means
without prior written authorization of Tata Consultancy Services.
Contents
1 BACKGROUND .............................................................................................1
2 WHAT ARE REAL-TIME SYSTEMS ................................................................1

2.1 INTRODUCTION ........................................................................................... 1
2.2 REAL-TIME P ROGRAMS: THE COMPUTATIONAL MODEL ............................................ 2
3 WHAT ARE EMBEDDED SYSTEMS ................................................................3
4 SOFTWARE DEVELOPMENT LIFE CYCLE......................................................3

4.1 REQUIREMENTS ANALYSIS ............................................................................... 4
4.1.1 Selection of RTOS ................................................................................. 4
4.2 ARCHITECTURE AND DESIGN............................................................................ 6
4.2.1 Modeling .............................................................................................. 7
4.2.2 Real-time Systems and Object Technology ............................................... 7
4.2.3 Design ................................................................................................. 8
4.2.4 Operating System Abstraction ............................................................... 10
4.2.5 Scheduling.......................................................................................... 11
4.2.6 Real-time Systems and COTS................................................................ 12
4.3 DEVELOPMENT .......................................................................................... 13
4.3.1 Cross-Platform development ................................................................. 13
4.3.2 Integrated Development Environment (IDE) ........................................... 14
4.3.3 Programming Language ....................................................................... 14
4.3.4 Debugging.......................................................................................... 16
4.3.5 Memory Management .......................................................................... 16
4.4 T ESTING ................................................................................................. 18
4.4.1 Dependencies on Non Existing Hardware and Software............................ 18
4.4.2 Code/Test Coverage Tools.................................................................... 18
4.4.3 Regression Testing .............................................................................. 18
4.4.4 Load/Capacity Testing.......................................................................... 18
5 REAL-TIME SYSTEMS—DEVELOPER’S PERSPECTIVE ............................... 18
6 FUTURE TRENDS AND CHALLENGES ........................................................ 19
7 REFERENCES ............................................................................................ 20
List of Figures
Figure 1: Timing Diagram (Source [1]) ..................................................................3
Figure 2: Linux and Real-time..................................................................................6
Figure 3: Example of a Message Sequence Diagram for a Microwave Oven......9
Figure 4: A State Chart Diagram............................................................................10
Figure 5: Cross Platform Development .................................................................14
Real-time Embedded Software Systems: An Introduction S. Agrawal & P. Bhatt Page 1 of 5
1 Background
This paper is based on our experience with the design and development of real-time
embedded software systems for the telecommunications industry and does not address
the aspects related to design and development of hardware for such systems. This
paper presents a software practitioner’s view of the real-time embedded software
systems and does not attempt to address the research areas in this domain. It therefore
caters to the needs of an informed reader in the software industry and to those who
want to have an overall idea about real-time embedded systems.
Readers interested in further details in this area are encouraged to refer to various
items listed in the “Reference” section provided at the end of this paper.
2 What are Real-time Systems
2.1 Introduction
Timeliness is the single most important aspect of a real-time system. These systems
respond to a series of external inputs, which arrive in an unpredictable fashion. The
real-time systems process these inputs, take appropriate decisions and also generate
output necessary to control the peripherals connected to them. As defined by Donald
Gillies “A real-time system is one in which the correctness of the computations not only
depends upon the logical correctness of the computation but also upon the time in
which the result is produced. If the timing constraints are not met, system failure is said
to have occurred.”
It is essential that the timing constraints of the system are guaranteed to be met.
Guaranteeing timing behaviour requires that the system be predictable.
The design of a real-time system must specify the timing requirements of the system
and ensure that the system performance is both correct and timely. There are three
types of time constraints:
§ Hard: A late response is incorrect and implies a system failure. An example of such
a system is of medical equipment monitoring vital functions of a human body,
where a late response would be considered as a failure.
§ Soft: Timeliness requirements are defined by using an average response time. If a

single computation is late, it is not usually significant, although repeated late
computation can result in system failures. An example of such a system includes
airlines reservation systems.
§ Firm: This is a combination of both hard and soft timeliness requirements. The
computation has a shorter soft requirement and a longer hard requirement. For
example, a patient ventilator must mechanically ventilate the patient a certain
amount in a given time period. A few seconds’ delay in the initiation of breath is
allowed, but not more than that.
One need to distinguish between on-line systems such as an airline reservation system,
which operates in real-time but with much less severe timeliness constraints than, say, a
missile control system or a telephone switch. An interactive system with better response
time is not a real-time system. These types of systems are often referred to as soft real-
time systems. In a soft real-time system (such as the airline reservation system) late
data is still good data. However, for hard real-time systems, late data is bad data. In
this paper we concentrate on the hard and firm real-time systems only.
Most real-time systems interface with and control hardware directly. The software for
such systems is mostly custom-developed. Real-time Applications can be either
embedded applications or non-embedded (desktop) applications. Real-time systems
often do not have standard peripherals associated with a desktop computer, namely the
keyboard, mouse or conventional display monitors. In most instances, real-time systems
have a customized version of these devices.
The following table compares some of the key features of real-time software systems
with other conventional software systems.
Feature Sequential Concurrent Real-time

Programming Programming Programming
Execution Predetermined order Multiple sequential Usually composed of

programs executing in concurrent programs
parallel
Numeric Independent of program Generally dependent on Dependent on program

Results execution speed program execution speed execution speed
Examples Accounting, payroll UNIX operating system Air flight Controller
2.2 Real-time Programs: The Computational Model

A simple real-time program can be defined as a program P that receives an event from
a sensor every T units of time and in the worst case, an event requires C units of
computation time.
Assume that the processing of each event must always be completed before the arrival
of the next event (i.e., when there is no buffering). Let the deadline for completing the
computation be D. If D < C, the deadline cannot be met. If T < D, the program must
still process each event in a time T, if no events are to be lost. Thus the deadline is
effectively bounded by T and we need to handle those cases where C D T.
An excellent source of reference for the mathematical modeling of real-time systems is

[1].
T T
C
Time
Inputs
Figure 1: Timing Diagram (Source [1])
3 What are Embedded Systems

Embedded systems do not provide standard computing services and normally exist as
part of a bigger system. A computerized washing machine is an example of an
embedded system where the main system provides a non-computing feature (washing
clothes) with the help of an embedded computer. Embedded systems are usually
constructed with the least powerful computers that can meet the functional and
performance requirements. This is essential to lower the manufacturing cost of the
equipment.
Other components of the embedded system are similarly chosen, so as to lower the
manufacturing cost. In conventional operating systems, a programmer needing to store
a large data structure can allocate big chunks of memory without having to think of the
consequences. These systems have enough main memory and a large pool of virtual
memory (in the form of disk space) to support such allocations. The embedded systems’
developers do not enjoy such luxuries and have to manage with complex algorithms to
manage resources in the most optimized manner.
In most of the real-life applications, real-time systems often work in an embedded

scenario and most of the embedded systems have real-time processing needs. Such
software is called Real-time Embedded Software systems.
Typical examples of embedded applications include microwave ovens, washing

machines, telecommunication equipment, etc.
4 Software Development Life Cycle

The development lifecycle of real-time software systems follows patterns similar to
those of a conventional software system. The development of real-time software
systems normally follows an iterative model, which caters to the addition of functionality
with each build of the system (hardware and software). The variations related to real-
time systems are discussed in the following sections.
4.1 Requirements Analysis

The requirements analysis phase of the software development life cycle (SDLC) covers
the user requirements of the system. It also must cover the real-time aspects of the
system in terms of timely response, reliability (down-time per year), performance
requirements (which includes the overall system performance, including the
throughput), fault tolerance, safety standards, government regulations (if applicable),
hardware deployment, software installation and upgrade. References to the hardware
platform (in terms of availability, capacity, form factor, etc.), cost targets, capacity, etc.
also need to be made, as these are crucial for software design.
4.1.1 Selection of RTOS

Most moderate-to-complex real-time systems use a real-time operating system or RTOS.
The RTOS is similar to a general purpose operating system and provides functions such
as:
§ Interface to the underlying hardware
§ Task scheduling and preemption
§ Memory management
§ I/O services
§ Support for your processor of choice
§ Portability to new processors
§ Scalability to match varied application requirements
§ Multiprocessor support
§ Extended services such as network support
§ Vertical application support (RTOS vendors have also begun to add services that
target specific vertical applications. For example, SNMP—Network Management
Protocol stack is offered along with pSOS RTOS.)
§ POSIX standards compliance — one trend that can help designers move from one
RTOS to another, is standards compliance. In particular, any RTOS that complies
with the POSIX standard would share a standard API (application programming
interface). LynxOS from the Lynx Real-time Systems is one RTOS that fully complies
with the POSIX standards.
Some of the areas where the RTOSs differ from conventional operating systems are:
§ Scheduling policies
§ Support for the embedded diskless environment

§ Licensing arrangements and price
§ Development environment
An RTOS is usually scaleable and is structured. It allows growth akin to the concentric
rings on a tree. The innermost ring or the kernel provides the most essential features of
the RTOS. Other features can be added as outer rings as necessary. The small kernel of
an RTOS makes it suitable for a small single processor application, whereas the outer
layers can help build large distributed real-time applications.
RTOSs most often provide priority-based task preemption. In this, the higher priority
task always preempts the lower priority task, when the former becomes ready to run.
Operating System issues such as “Priority Inversion” need to be considered in such
priority-based preemption.
RTOSs are often tailored to meet embedded systems’ requirements. These typically
provide the ability to boot from the ROM, for systems without any disk storage. Some
systems can even work with only ROM, thus significantly reducing the boot-time of the
system.
One must ask the vendor for information in the following areas, while making a
selection for a real-time operating system:
§ The interrupt latency (i.e. time from interrupt to task run): this has to be compatible
with application requirements and has to be predictable. This value depends on the
number of simultaneous pending interrupts.
§ The maximum time taken by various system calls — it should be predictable and
independent of the number of objects in the system.
§ The maximum time the operating system and drivers mask the interrupts.
Besides a good kernel, a good RTOS must also have user-friendly documentation and
support for good tools for development.
Some examples of RTOSs are:
§ VxWorks and pSOS by Wind River
§ OSE by Enea
§ LynxOS by LynuxWorks
§ OS-9 by Microware
4.1.1.1 Linux and Real-time

Linux is a general-purpose operating system and is designed for average performance.
It achieves this performance by a fair sharing of processor among the processes.
Linux Processes
Linux Kernel RT Processes
Software
Interrupts Scheduling
Hardware
Figure 2: Linux and Real-time
The Linux virtual memory implementation can swap out any process. Linux processes
are heavyweight and there are significant overheads in process switching. The Linux
kernel is non-preemptive, i.e., a process in the midst of a system call cannot be
preempted. Linux also disables interrupts in the critical sections of the kernel code. Due
to these reasons, Linux in itself is not suitable to meet the timing requirements of a hard
real time system.
Real Time Linux (RT-Linux) addresses this problem by slipping in a small real-time
kernel underneath Linux and running Linux as a process within its control. The control is
transferred to the Linux process whenever there is no processor requirement from a
real-time process. The following diagram depicts the operating model of RT-Linux.
Communication between the Linux and RT-Linux processes is generally achieved using
the FIFO connections or shared memory segments.
4.2 Architecture and Design

The architectural design of a system identifies the key strategies for the large-scale
organization of the system under development. These strategies include the mapping of
software packages to processors, bus, and protocol selection, and the concurrency
model and task threads. The building blocks of real-time software subsystems are tasks
and packages. A task is the smallest unit of execution that gets the processor resources.
Tasks comprise the program-level decomposition of the software system. Multiple tasks
execute concurrently to achieve the system functionality. Packages comprise the
functional-level decomposition of the system functionality and model a single area of
concern or domain. Packages may contain sub-packages and in Object Oriented analysis
and Design (OOAD) terminology, their primary components are objects and classes.
Specifically, they contain objects and classes representing important concepts within a
given domain. Class generalization hierarchies are always within a single package.
Subsystems are often organized as a set of layered packages. Many complex systems
have several layers ordered hierarchically from the most abstract (closest to the
application domain), down to the most concrete (closest to the underlying hardware).
It is most efficacious to design a layered architecture and actually implement the system
as a series of vertical slices of functionality that cut through all layers. ISO’s seven-layer
reference model is a common layered architecture for communications protocols. A
layered implementation strategy would build each layer independently and link them
together as they are completed. However, this approach has been proven to be risky
and expensive in practice because fundamental flaws that affect the overall subsystem
functionality are not caught until integration. A better implementation strategy is to
implement vertical slices. Each vertical slice implements only the portion of each layer
relevant to the purpose of the slice. This approach to implementation is called iterative
prototyping and each slice is called a prototype. The prototypes are implemented so
that each prototype builds upon the features implemented in its predecessors. The
sequence of prototypes is decided based on which features logically come first as well
as which represent the highest risk. By doing risk-based development, higher risk items
are explored and resolved as early as possible. This typically results in less rework and a
more integrated reliable system.
4.2.1 Modeling
Modeling is a proven and a well accepted engineering technique. Modeling is of more
significance in real-time systems, because of the their mission-critical usage, as in a
nuclear reactor or in flight navigation systems. The designers should be able to visualize
all possible requirements of the application and predict the system behaviour timeliness
accurately in each case; modeling helps the designers in this task. Real-time systems
follow the modeling techniques to visualize, control and document the application’s
system architecture and behaviour.
4.2.1.1 Unified Modeling Language

One of the most common modeling techniques prevalent in industry is the Object
Modeling Technique (OMT) which can be realized using Unified Modeling Language.
There are various UML tools available in the market, namely Rational Rose, iLogix –
Rhapsody, and also Adex, TCS’ UML Modeling tool.
4.2.1.2 Specification and Description Language

SDL is a standard language to specify and describe systems. SDL was conceived for use
in telecommunication systems, but it may be used in all kinds of real-time
communicating systems. It describes the co-operation of these systems with their
environment. It is, in general, possible to specify various aspects of a system, such as
hardware design, physical dimensions, power consumption, and so on. SDL is concerned
with the specification of the behaviour, structure and data.
4.2.2 Real-time Systems and Object Technology

The object oriented programming paradigm is a good fit for the design and
development of the real-time systems, as it tries to simulate the physical world (the
environment). The software—at a higher level—is specified as components interacting
with each other. However, the hesitation in using the object technology comes from the
perception that it entails unacceptably high memory and performance overheads for a
real-time system. The abstraction mechanisms, such as polymorphism and
encapsulation, can definitely induce overheads, but if seen in conjunction with the
increasing power of the hardware, may still make the object technology a suitable
candidate for real time development.
4.2.3 Design
4.2.3.1 Message Sequence Diagrams

A message sequence diagram emphasizes the timing ordering of messages between
objects (entities).
The following message sequence diagram shows the message interaction between a
microwave user and a microwave oven.
Figure 3: Example of a Message Sequence Diagram for a Microwave Oven
4.2.3.2 State Machines/State Chart Diagrams

A state machine is a behaviour that specifies the sequences of states an object (entity)
goes through during its lifetime, in response to events, together with its responses to
those events.
A state chart diagram shows a state machine. This diagram models the dynamic aspects
of a system.
The following example shows the state chart diagram for a commonly used real-time
embedded system—a microwave oven. This shows the various states in which a
microwave oven can exist, namely,—Off, Idle, Heating and Pause. The arrows between
the states show the state transitions.
Figure 4: A State Chart Diagram
4.2.3.3 Animation
Animation is the act of executing a model. Animation is not the same as simulation. An
animator actually runs the real application, if desired, on the target machine. This gives
the developer a better idea of the system’s behaviour than merely simulating it.
Animation can be done using Message Sequence Charts and State Chart diagrams.
4.2.4 Operating System Abstraction

The Operating System Abstraction layer can be developed on top of the system calls.
The developers will not directly make the OS system calls; instead, they will make a call
to the abstraction layer methods. If in future, the OS is changed or upgraded, only the
methods would change internally, the rest of the system would not get affected.
4.2.5 Scheduling
Task scheduling is an important aspect of real-time systems. Real-time software
executes in response to external events. These events may be periodic, in which case,
an appropriate scheduling of events and related tasks is required to guarantee
performance. The scheduling strategy also depends on scheduling facilities that the
chosen RTOS offers, but in general, RTOSs are flexible with scheduling.
4.2.5.1 Static Scheduling

This involves analyzing the tasks statically and determining their timing properties.
These timing properties can be used to create a fixed scheduling table, according to
which tasks will be despatched for execution at run-time. Thus, the order of execution
of tasks is fixed, and it is assumed that their execution times are also fixed.
Round Robin by Time Slicing

Round Robin by time slicing is one of the ways to achieve static scheduling. Round robin
is one of the simplest and most widely used scheduling algorithms, in which a small unit
of time (called a time-slice) is defined. The CPU scheduler goes around a queue of
ready-to-run processes and allocates a time slice to each such process.
Scheduling with priorities

Priority indicates the urgency or importance assigned to a task. The following are the
two approaches followed when scheduling is based on priority.
Priority Based Execution

When the processor is idle, the ready task with the highest priority is chosen for
execution; once chosen, a task is run to completion.
Preemptive Priority-based Execution

When the processor is idle, the ready task with the highest priority is chosen for
execution; at any time, the execution of a task can be preempted if a task of higher
priority becomes ready. Thus, at all times, the processor is idle or executing the ready
task with the highest priority. This approach is followed in the pSOS operating system.
4.2.5.2 Dynamic Scheduling

Dynamic scheduling of a real-time program requires a sequence of decisions to be taken
during execution on the assignment of resources to transactions. Each decision must be
taken without prior knowledge of the needs of future tasks. Dynamic algorithms are
needed for applications where the computing requirements may vary widely, making
fixed priority scheduling difficult or inefficient. This kind of scheduling allows flexibility to
alter scheduling based on:
§ Environment changes
§ Burst of task arrival
§ Partial system failure.

Dynamic scheduling has the following basic steps.
Feasibility checking
Feasibility checking is the process of determining whether the timing requirements of a
set of tasks can be satisfied, usually under a given set of resource requirements and
precedence constraints.
There are two approaches to feasibility-checking in dynamic real-time systems:
Dynamic planning-based approach: Here the feasibility of a set of tasks is checked in

terms of a scheduling policy such as ‘earliest-deadline-first’ or ‘least-laxity-first’.
Dynamic best-effort approach: Tasks may be queued according to policies that take
account of time constraints. No feasibility checking is done before the tasks are queued.
Schedule construction
Schedule construction is the process of ordering the tasks to be executed and storing
this in a form that can be used by the despatching step.
Despatching
Despatching is the process of deciding which task to execute next.
4.2.5.3 Scheduling Overheads

Simple scheduling analysis usually ignores context switches and queue manipulations,
but the time for this is often significant and cannot realistically be assumed to be
negligible. The time taken should be considered when deciding on the scheduling
algorithm.
4.2.6 Real-time Systems and COTS

Use of commercially available off-the-shelf (COTS) software in the design of real-time
embedded systems is prevalent these days as this helps the companies meet the
aggressive time-to-market requirements within the given schedule and budget. As most
of these COTS packages are proven in the industrial applications, the risk is also
reduced significantly.
Selection of the right product (and vendor) is critical for the success of any COTS-based
project. The financial stability of the vendor is definitely one of the key parameters to be
looked into before deciding on a COTS package offered by the vendor. In addition to
this, the geographical spread, availability of local support for a long term, and
responsiveness of the vendor in addressing the reported problems must be taken into
account. It may be worthwhile to conduct a detailed evaluation of the product to
determine its applicability in meeting the requirements. This evaluation should also take
into account the compatibility issues at a broader level with other software packages
under consideration for the product under development. Having historical data on the
integration of various packages is definitely helpful. This data can normally be received
from other projects that have already done such an integration exercise or a similar one.
One more important aspect to be considered while making the selection of the RTOS is
the availability of tools (for example, code coverage, memory leak detection, etc.).
The COTS package selection must show substantial savings in the costs and should be
weighed against the risk of losing control (by using the COTS software). The evaluation
process must take factors other than the financial and technical into account while
making the selection of the COTS package.
4.3 Development
Real-time systems usually have varied requirements:
§ Functional/business requirements of the system
§ Requirement to support and manage the special hardware of the system
§ Requirements to monitor the system, so as to have minimum down time of the

system.
Such varied requirements generally necessitate the use of multiple development tools.
The following should be verified before the tools are finalized:
§ Integration of various tools with the RTOS and also integration of various
development tools amongst themselves (compatibility with each other).
§ Some of these tools will run on the host machine and in such cases, their
integration with the host operating system must be kept in mind.
§ Run-time requirements of the executables generated by these tools.
§ The memory requirements of the COTS components should be well within the
overall resources available to the system.
The list of development tools includes the modeling tools, cross-platform development
tools, programming language, IDE, configuration management tools, test coverage
tools, memory leak detection tools, etc.
4.3.1 Cross-Platform development

The Cross-platform development means that the development is done on a different
platform (called the source or host platform) than the one on which the system will
actually be run (called target platform). For example, a system is developed on
Windows NT and it is then downloaded onto a custom hardware running a separate
RTOS, for the purpose of testing.
Cross-platform development brings issues related to differences in the source and target
environment. The developers should develop the system as per the facilities available on
the target environment and not what is available on the host. For example, the target
RTOS may not provide all standard C/C++ libraries, which are otherwise available on a
typical Windows/Unix setup, so such libraries cannot be used. Further, the code has to
be built (compiled and linked) for the target environment.
Figure 5: Cross Platform Development
4.3.2 Integrated Development Environment (IDE)

IDE includes language compilers, debuggers, editors, and a source code control system.
Green Hills, for example, offers its MULTI environment for a number of RTOS platforms,
including pSOS and VxWorks. MULTI is a multi-language embedded development
environment featuring source-level debugging, execution profiling, memory leak
detection, graphical class browser, program builder, editor, and source code control.
MULTI can be hosted on PCs, Unix Workstations, and VAX/VMS systems and supports a
number of target processors, including the 68k, i960, and MIPS.
Despite the advantages of using a development environment from a third party, some
designers may find it more advantageous to use a totally integrated environment from a
single vendor. When a single vendor develops both pieces of code, the development
environment can include features that are RTOS-aware. Microware, for example, offers
a comprehensive development called FasTrak for OS-9 that includes the C compiler,
source control, debugger, and other features. The FasTrak debugger is one module that
provides designers with substantial advantages based on its close ties with the RTOS. It
can display a broad range of CPU and OS resources, including: CPU and FPU registers,
stack frames, local variables, and target system memory. Moreover, it can display and
control RTOS task-level resources.
4.3.3 Programming Language

The choice of programming language is very important for real-time embedded
software. The following factors influence the choice of language:
§ A language compiler should be available for the chosen RTOS and hardware
architecture of the embedded system.
§ Compilers should be available on multiple Operating systems and microprocessors.

This is particularly important if the processor or the RTOS needs to be changed in
future.
§ The language should allow direct hardware control without sacrificing the
advantages of a high-level language.
§ The language should provide memory management control such as dynamic and
static memory allocation.
§ Real-time systems are increasingly being designed using Object Oriented (OO)
methodology and using a language that supports OO concepts is definitely helpful.
The languages that are typically used for embedded systems are Assembly Language, C,
C++, Ada and Java.
Choosing to write code in Assembler should be done on a case-by-case basis. While

code written in Assembler can be much faster, it is usually very processor-specific and
less portable than a high-level language.
C is by far the most popular language and the language that maximizes application
portability. C++ is used when real-time applications are developed using object-oriented
methodology.
Members of the scientific community, for example, have millions of lines of existing
Fortran code that implement proprietary numerical algorithms. Likewise, developers
targeting military applications (for the USA) may require Ada.
The availability of languages for a development project is limited to the languages that
have been ported to a specific RTOS environment, and in some cases, to languages that
have been ported to a specific target single-board computer.
Some RTOS vendors offer their own versions of popular languages as they optimize the
compiler for RTOS architecture. Microware, for example, has its own C compiler called
Ultra C.
4.3.3.1 Java and Real-time Development

Real-time Specifications for Java (RTSJ) attempts to bring the benefits of Java to real-
time programming. The RTSJ recommend a limited set of modifications to the language
specifications and the Java virtual machine specifications. Implementation of RTSJ will
be implemented on traditional real-time operating systems and will focus on embedded
device targets. Enterprise-level implementations and implementations on platforms such
as Real-Time Linux are also likely. The RTSJ specify enhancements to the Java language
in the following seven areas:
§ Scheduling
§ Memory Management
§ Synchronization
§ Asynchronous Event Handling
§ Asynchronous Transfer of Control
§ Asynchronous Thread Termination
§ Physical Memory Access

IBM's VisualAge Micro Edition provides the environment, tools, and runtime support for
building complete, end-to-end embedded systems based on Java technology.
4.3.4 Debugging
Once the executable binary image is downloaded onto the target machine for testing
purposes, the need to set break points in the program, to observe the execution, arises.
4.3.4.1 Remote Debugger
In embedded systems, the debugger and the software being debugged execute on two
different computer systems. The remote debugger can be used to download, execute
and debug embedded software over a serial port or network connection between the
host and the target. Some examples of remote debugging tools are CADUL XDB for
pSOS, or CrossWind for VxWorks.
4.3.4.2 Emulators
Remote debuggers are useful in monitoring and controlling the state of real-time
embedded software. However, only an in-circuit emulator (ICE) allows the developer to
examine the state of the processor on which the program is running. ICE emulates the
target board processor. It is an embedded system with its own copy of the target
processor, RAM, ROM and its own embedded software. As a result, ICE is usually very
expensive. Emulators are useful in real-time tracing of the target processor. It can store
the information for each of the processor cycles that are executed, so that the
developer can see in exactly what order things happened.
4.3.4.3 Simulator
Another commonly used debugging tool is Simulator. A simulator is a host-based

program that simulates the functionality and instruction set of the target processor.
Embedded systems have to frequently interact with external devices and this may be
difficult to imitate with simulator scripts or other workarounds.
For example, VxSim is a complete prototyping and simulation tool for Tornado or
VxWorks applications. It enables application development to begin before hardware
becomes available, allowing a large portion of software testing to occur early in the
development cycle.
4.3.5 Memory Management

Real-time systems allocate memory dynamically during their execution. The following
points need to be catered to when designing the embedded software:
§ Set up application partition at launch time—create all tasks initially (at start up),
create stack space for all the tasks
§ Determine the amount of free memory in the application heap
§ Allocate and dispose blocks of memory (in the application heap) using partitioned
memory, which has fixed-size buffers
§ Minimize fragmentation in the application heap caused by blocks of memory that

cannot move
§ Implement a scheme to avoid low-memory conditions
Memory Fragmentation is a common problem when dynamic memory allocation (use of

malloc()/ new() in C/C++) is used. In order to prevent this from happening, real -time
systems use partitioned memory, which has fixed-size buffers. A good approach is not
to use dynamic object creation and create objects at the startup itself.
For hard real-time systems, there is almost no opportunity to do any dynamic memory
allocation/retrieval and dynamic memory allocation should be minimized for systems
having soft/firm timing requirements. RTOSs do not provide efficient protection against
an overflow of memory stacks, as provided by traditional operating systems. So, one
would need to keep in mind the maximum stack size allowed for the functions, while
declaring local variables of the function. If the total size of local variables exceeds the
maximum limit of stack allowed, then the system can overwrite the data in the other’s
memory area. This does not apply in the case when in C++, “new” is used because
“new” allocates memory from the heap, not from the stack.
Some RTOSs do not have task-level memory protection implemented, so memory

diagnostics is required to check for memory corruption.
4.3.5.1 Memory Diagnostics Tools
These tools are effective in detecting problems related to the memory usage of a real-
time software system. Some of these are described in the following text.
Memory leaks
Defined as memory, which is allocated but not released when the intended functionality
is achieved. This generally occurs in C/C++ with calls to malloc()/new() and the
corresponding free()/delete() not being called appropriately.
Low Memory Corruption

Defined as the corruption of the lowest memory addresses of the RAM, which usually
stores the Operating system functions such as Interrupt Service Routines.
void test (void) {

int *ptr;
*ptr = 0xABCDABCD;
}
For example, this code will corrupt the low memory, since memory has not been
allocated for the pointer variable ptr.
Buffer Corruption
Defined as writing more data than the storage allocated. This typically can occur, when
say, 200 array indexes have been allocated in C / C++ and data is written to the 200th
index, whereas storage has been allocated for 0 to 199 indexes only.
4.4 Testing
Verification tools allow a designer to run software against a hardware design before a
prototype has been built. They accomplish this by executing the software on a logic
simulation of the hardware design. However, logic simulations are notoriously slow,
typically running at about 1 to 10 clock cycles per second on complex designs.
4.4.1 Dependencies on Non-existing Hardware and Software

Real-time systems typically involve both hardware and software. Most often, the
development of both the hardware and software may be done in parallel, so the
hardware may not be available for doing the preliminary testing of the software.
Further, the hardware may be quite expensive and not available to the development
team. Such cases necessitate the simulation of the hardware environment either using
software (in the form of test stubs or simulators) or some other hardware. The design
of the simulation environment becomes very important for the success of the project.
4.4.2 Code/Test Coverage Tools

The way to make sure that the developer has got all the control flow covered is to cover
all the paths in the program during the testing (via white-box testing). Such tools
quickly find untested code and measure testing completeness. Also, they increase
testing productivity by showing whether or not your application encountered all the
conditions to which it is sensitive. The tester can generate test cases faster by looking
only at the untested parts of the application, and find defects that would not have
otherwise been found, as in the CodeTEST for Tornado from VxWorks.
4.4.3 Regression Testing

Regression testing involves subjecting a program or system to all the tests—with the
same data—performed earlier, to prove that any changes made to correct errors in tests
would not have introduced new errors. In real-time systems, more regression testing
needs to be done, as compared to conventional applications, depending upon the
mission-critical nature of the application. A set of test specifications can be developed
for this purpose, which covers the main features, as well as the critical features of the
application.
4.4.4 Load/Capacity Testing

Real-time systems should be able to run at the maximum load for a prolonged period of
time. Telecommunication equipment is supposed to run 365 days a year without any
service interruption. Scripting languages (e.g. TCL) can be used to write scripts to do
the maximum capacity testing. Scripts can be run in a batch mode overnight, to
repeatedly run the same test cases.
5 Real-time Systems—Developer’s Perspective

From a software developer’s point of view, the real-time software systems pose a few
challenges, which are normally not applicable for the conventional software. Some of
these are described in the following text:
§ Real-time software systems are generally more complex to develop than the
conventional systems. More training is required for developers who will work on
such systems, due to the following requirements:
§ Understanding of the RTOS and Cross-Platform Development.
§ More testing is required in order to ensure more reliability.
§ Lack of Memory Diagnostics tools in the market.
The development team needs to be identified much in advance and trained

appropriately.
§ Host-target based testing environment requires downloading of the executable on

the target and then debugging via the host. Thus, this requires more time to run a
test case, as compared to systems in which no cross-platform development is done.
The testing phase of the project may take more time due to this reason.
§ The usage of global memory should be minimized.
§ Designer/developer should have some knowledge of deployment configuration of

the embedded system. This will help in coming up with special test cases, as many
embedded systems do not operate in a controlled environment. A typical example is
the outdoor installation of telecommunication systems. Such systems are prone to
harsh weather conditions such as water flooding, or high/low temperatures. The
system should be capable of warning the users in the likelihood of failure due to
such environmental conditions.
§ Performance improvement techniques such as usage of the C language

memset()/memcpy() should be done wherever string manipulations are being done,
instead of using the for loop and changing the memory location character by
character.
§ In some environments, it may be desirable or necessary to write and debug the

code first in a PC environment and later port or recompile it for the embedded
processor. It will be better to write the code in such a way that it supports both
platforms based on compile switches, libraries or classes that abstract the operating
system.
6 Future Trends and Challenges

In the last decade, we have seen a tremendous interest in real-time embedded systems.
While the hard real-time embedded systems deployed in the process control and factory
automation application have retained their position, softer embedded systems in the
smart devices coming into the market, which can be networked together, have shown a
consistent technological advancement. Advances in the networking area itself have
given a tremendous boost to the real-time embedded space. We have also seen
advancements in the wireless domain, giving us the ability to compute anytime and
anywhere. The hardware devices have also shown advances in the area of power
consumption (low-powered devices) thereby making these more suitable to embedded

applications and the design of high-powered digital signal processing chips.
At present, the tools available to support embedded programming are mostly derived
from those used for general-purpose programming tools. These tools will become more
appropriate for real-time embedded needs in the future.
The most promising applications would be in the area of telecommunications and

networking. Whether it be an embedded microprocessor in some kind of server I/O
device, network infrastructure equipment, or consumer devices, networking protocols
and applications are likely to dominate embedded applications. Entertainment (audio-
visual) would be another key area driving the growth of real-time embedded systems.
In the operating system market, we may see consolidation with fewer and more robust
alternatives being available to the developers. The tools for supporting the development
of real-time embedded systems would also see significant advancement particularly
since the size of embedded applications is constantly growing, thereby making these
more complex to develop, test and maintain. The operating system market is also likely
to see the componentized operating systems, offering developers the facility to choose
the relevant components meeting the need of their applications.
The major challenges for the real-time embedded systems in the future (based on their
application) are going to be security, scalability (high) availability, and performance with
deterministic behaviour. As the real-time embedded systems become more complex in
future, maintaining them would be a big challenge. The new interactive applications of
the future may require their systems meeting stringent time constraints. Defining
distributed computing models for real-time embedded systems for networked embedded
systems, inter-operability and fault tolerance will also pose challenges, particularly in the
area of standardization of interfaces for communication between these systems.
7 References
1. Mathai Joseph, Real-time Systems: Specification, Verification and Analysis, Prentice
Hall International, London, 1996
2. Bran Selic, Turning Clockwise: Using UML in the Real-Time Domain,

Communications of the ACM, October 1999.
3. Bruce Powell Douglass, Real-time UML Developing Efficient Objects for Embedded
Systems, Addison Wesley 1998.
4. Comp.realtime FAQ, newsgroup comp.realtime
5. Choosing an Operating System for Embedded Real-Time Applications,

http://pats.crane.navy.mil/pubdoc/choosos.htm
6. David L Ripps, An Implementation Guide to Real-time Programming, Prentice-Hall

Inc., 1989
7. David Hardin, The Real-Time Specification for Java, Dr. Dobb’s Journal, February
2000.
8. http://www.embedded.com
9. ETSI (European Telecommunications Standards Institute) documents

(http://www.etsi.org)
10. Frederick M. Proctor, Linux, Real-Time Linux, & IPC, Dr. Dobb’s Journal, November
1999.
11. Grady Booch, James Rumbaugh, Ivar Jacobson, The Unified Modeling Language
User Guide, Addison Wesley.
12. Greg Bollella, Ben Brosgol, Peter Dibble, Steve Furr, James Gosling, David Hardin,
Mark Turnbull, The Real Time Specification for Java, Addison Wesley, June 2000,
http://www.rtj.org
13. ITU (International Telecommunication Union) documents http://www.itu.int
14. Jan Ellsberger, Dieter Hosgrefe, Amardeo Sarma, SDL – Formal Object Oriented
Language for Communicating Systems, Telelogic. Prentice Hall
15. Michael Barabanov, Victor Yodaiken, Real-Time Linux, 1996
16. Michael Barr, Programming Embedded Systems in C and C++, O’Reilly Associates,
August 1999.
17. Milojicic Dejan, Trend Wars – Embedded Systems, IEEE Concurrency, October-
December 2000
18. Request For Comments – RFC (http://www.ietf.org)
19. Robert Rosenberg, Lessons Learnt Using COTS in Real-Time Embedded Systems,
Presented to the Joint Avionics and Weapons Systems Support Software and
Simulation Conference, June 1998, http://www.sabresys.com/whitepapers/cots.html
20. Strength and Structure in Real Time Operating Systems,

http://www.enea.com/PRODUCT/papers/strength.htm
21. Testing Guidelines, Tata Consultancy Services, December 1997.

RTSS 4

Uploaded by

Copyright:

Available Formats

RTSS 4

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

RTSS 4

Uploaded by

Copyright:

Available Formats

Real-time Embedded Software Systems: An Introduction S. Agrawal & P.

Technology Review #2001-04

© Copyright 2001 Tata Consultancy Services. All rights reserved

2 WHAT ARE REAL-TIME SYSTEMS ................................................................1

4 SOFTWARE DEVELOPMENT LIFE CYCLE......................................................3

6 FUTURE TRENDS AND CHALLENGES ........................................................ 19

2 What are Real-time Systems

§ Soft: Timeliness requirements are defined by using an average response time. If a

Feature Sequential Concurrent Real-time

Execution Predetermined order Multiple sequential Usually composed of

Numeric Independent of program Generally dependent on Dependent on program

Examples Accounting, payroll UNIX operating system Air flight Controller

2.2 Real-time Programs: The Computational Model

An excellent source of reference for the mathematical modeling of real-time systems is

Figure 1: Timing Diagram (Source [1])

3 What are Embedded Systems

In most of the real-life applications, real-time systems often work in an embedded

Typical examples of embedded applications include microwave ovens, washing

4 Software Development Life Cycle

4.1 Requirements Analysis

4.1.1 Selection of RTOS

§ Interface to the underlying hardware

§ Task scheduling and preemption

§ Support for your processor of choice

§ Portability to new processors

§ Scalability to match varied application requirements

§ Extended services such as network support

§ Support for the embedded diskless environment

§ Licensing arrangements and price

Some examples of RTOSs are:

§ VxWorks and pSOS by Wind River

4.1.1.1 Linux and Real-time

Linux Kernel RT Processes

Figure 2: Linux and Real-time

4.2 Architecture and Design

4.2.1.1 Unified Modeling Language

4.2.1.2 Specification and Description Language

4.2.2 Real-time Systems and Object Technology

4.2.3.1 Message Sequence Diagrams

Figure 3: Example of a Message Sequence Diagram for a Microwave Oven

4.2.3.2 State Machines/State Chart Diagrams

Figure 4: A State Chart Diagram

4.2.4 Operating System Abstraction

4.2.5.1 Static Scheduling

Round Robin by Time Slicing

Scheduling with priorities

Priority Based Execution

Preemptive Priority-based Execution

4.2.5.2 Dynamic Scheduling

§ Burst of task arrival

§ Partial system failure.

Dynamic scheduling has the following basic steps.

There are two approaches to feasibility-checking in dynamic real-time systems:

Dynamic planning-based approach: Here the feasibility of a set of tasks is checked in

4.2.5.3 Scheduling Overheads

4.2.6 Real-time Systems and COTS

Real-time systems usually have varied requirements:

§ Functional/business requirements of the system

§ Requirement to support and manage the special hardware of the system