Real Time Embedded Software Systems

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


© 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 PROGRAMS: 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 TESTING ................................................................................................. 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 Programming

Concurrent Programming

Real-time Programming

Execution Predetermined order Multiple sequential programs executing in parallel

Usually composed of concurrent programs

Numeric Results

Independent of program execution speed

Generally dependent on program execution speed

Dependent on program 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].

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.

T

Time

C

T

Inputs


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.


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.

Software Interrupts Scheduling

Hardware

Linux Kernel

RT Processes

Linux Processes


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.

Documents

Real Time Embedded Software Systems