TERM PAPER

SOFTWARE DESIGN METHODOLOGIES FOR

EMBEDDED SYSTEMS

By

Subhashini Srinivasan

October 23, 2003

SOFTWARE DESIGN METHODOLOGIES FOR

EMBEDDED SYSTEM SOFTWARE

ABSTRACT

One of the traditional definitions of software is that it is a set of instructions executed in sequence in finite steps in finite time. This definition of software has been the bedrock for the development of software engineering practices over the past few decades. Software has been consistently abstracted away from the real world to be viewed as a set of functionalities. Embedded software does not fit into this mould of software definition. It deals with the real world continuously under severe constraints of time, reliability and resources. Consequently, existing software engineering practices do not adapt themselves well to this new paradigm. The prevalent design methodologies of ESW are primitive and inefficient. Increasing complexity of embedded applications is forcing a new approach towards the development of ESW. This paper explores why prevalent software engineering practices fall short in designing embedded software, existing scenarios and the design challenges in ESW. New approaches to software design for ESW involving higher abstraction levels and design re-use at all levels of abstraction are explored in this paper.

1. INTRODUCTION:

1.1 What are embedded systems?

Embedded systems are electronic components of a physical system such as a vehicle or a communications system that monitor variables of the physical system. The information is processed using some mathematical model of computation and the output signals are used to control the system or the environment. An embedded system is not a general purpose processor. It is tailored to perform one highly specialized task efficiently. Embedded systems are widely used in a variety of applications such as heart monitors, airplanes, climate control systems, cars, microwaves etc…

1.2 Implementation of embedded systems:

Implementation of embedded systems can range from a full hardware configuration to a full software implementation. In the hardware configuration, the functionalities to be implemented are mapped to a set of integrated circuits. In the software configuration, the functionalities are translated to a set of software processes.

1.3 Why Embedded Software?

In the past, hardware configurations were heavily relied upon. But increasing sophistication of embedded systems and dynamically evolving specifications have forced designers to look at flexible solutions. In hardware implementations, designers are working at levels of abstraction too close to implementation. Therefore sharing of components and design reuse is not possible. Making changes is tedious in hardware configurations since hardware manufacturing cycles are long. Thus software has emerged as a strong, flexible and viable alternative for the implementation of complex embedded systems. Embedded software is thus an “implementation choice of a functionality”[6] in which we cannot abstract away the hard characteristics of software such as time and power consumption.

2. CHALLENGES IN THE DESIGN OF ESW:

The challenges in the design of ESW are as follows:

2.1 Timeliness:

Embedded software, due to its continual interaction with the physical world, acquires some properties of the physical world. Time is a concept that has been abstracted away from traditional theories of computation. However, in the real world, computation does take time. And in the case of embedded systems employed in application domains where time is critical such as nuclear reactors or airplane navigation systems, a matter of nanoseconds can make a vital difference. A large part of performance gain has been in statistical speed-ups such as caching schemes, dynamic dispatch etc…These techniques cannot be applied to ESW because the physical processes with which ESW deals with, evolve with time. Therefore, software designers have to come up with an abstraction that has to take time into account in all computations.

2.2 Concurrency:

Embedded systems rarely react with one process at a time. They react with multiple real world processes concurrently. Therefore, concurrency control and handling is important for ESW. In general purpose software practice, concurrency control is primitive. Reconciling the sequential nature of software and the concurrency of the real world is a key challenge for embedded software designers.

2.3 Liveness:

In Turing’s model of computation, all procedures that do not terminate fall into an equivalence class called defective procedures. However, embedded systems cannot afford to fail or terminate. Terminating programs are defective.

2.4 Dependence on hardware:

In traditional software, the hardware does not have a major role to play in testing the software design. However, since embedded systems are closely interlinked with the physical system, they require hardware dependence and support for testing and debugging. The functionality of the software is tightly bound with the hardware. This fact plays havoc on the design of ESW. Since the software being developed is highly specific to a domain, designers make use of platform specific constructs in their code. This invalidates design re-use concepts, especially in complex ESW.

3. CONSTRAINTS OF TRADITIONAL SOFTWARE ENGINEERING METHODS:

Construction of complex ESW can benefit from components. Software Engineering has experienced major advances in design re-use in terms of components and interfaces. The most ancient and widely used component based technology is a procedure. However, procedures are a bad match to embedded software. Not many things in ESW can be represented as procedures because procedures are terminating and finite. Processes have a better mapping. However, processes cannot be composed to yield another process with a defined interface. This inability of processes to be composed makes them ineligible for ESW. Component based architectures such as COM, CORBA and Jini have been developed in the recent past to work well with traditional software. Components in traditional software are defined to be generic and subject to third party re-use. But as far as ESW is concerned, the application domain is highly specific and almost no third party will ever use these components. Also, the above components are heavy weight and ill suited to the nature of ESW.

Though object oriented methods do yield a cleaner decomposition of the program and add structure to the code, they are static. Objects are passive and require external invocation of their methods. ESW requires “active objects” that have processes that get invoked under specific circumstances without prodding. Also the processes have to be made compositional whose behavior can be predicted and controlled at real-time. Thus existing object oriented methods have to be augmented.

4. EXISTING STATE OF ESW:

Since embedded software has tight time and resource constraints, most of the coding is still done in assembly language. ESW needs hardware support for debugging and performance evaluation that is not a major concern for traditional software. Most designers work too close to the implementation level to improve design methodology and promote software re-use. However, with increasing sophistication of embedded systems, this is becoming a bottleneck. Software design methodology has to be improved to improve productivity. Object oriented methodologies will evolve a cleaner code. But ensuring a sound development process will ensure better products.

Embedded software cannot be viewed in isolation of the developments in IC technology. With the increasing advances in IC manufacturing, designers are turning to programmable platforms. More and more burden is placed on the IC provider who has to provide not only the platform but also the tools for mapping software onto the platform. Development tools are currently provided only by third parties. Inconsistent interfaces provided by these third parties further complicate the job of the system designer. The SoCs should be designed with good characterizations of the applications that will run on it and ESW should be designed with a good understanding of the capability of the SoC.

The design of ESW and the corresponding hardware are so intertwined. Therefore, in order to produce a good design, the underlying hardware should be understood properly. Thus function-architecture co-design becomes an important ideal. The new system design paradigm becomes “orthogonalization of concerns”[1]; i.e. the separation of various aspects of design to enable better exploration of alternative solutions.

An improvement in ESW design methodologies would involve the collaboration of software designers, hardware designers and system manufacturers. These traditionally isolated worlds have to collide to yield better embedded systems.

5. APPROACHES TO ESW DESIGN:

In order to ensure better ESW design, the approach should be holistic. Software should only be an implementation aspect and not the design aspect. The system specifications should be captured at some higher level of abstraction independent of the language used for implementation. Emphasis should be placed on mathematical models for description. Only a high level view of the problem that includes supporting tools, methodology and software platforms will have a real impact on embedded systems. One approach that has been suggested is to link ESW upwards in the abstraction layers to system functionality and linking ESW to the programmable platforms that support it [7]. This is essential because ESW requires hardware support for debugging and performance evaluation but it should also be independent of the hardware layers.

The essential issue to resolve is the link between functionality and programmable platforms. The high level abstraction should be completely implementation independent. The design methodology can be broken into the following goals:

5.1 Specification:

Specification is the entry point to the design process. The specification should be expressed as a set of equations and inequalities in an appropriate algebra. The specification should also capture the set of constraints that have to be satisfied by the final implementation. These constraints can also be expressed as equalities and inequalities. A set of design criteria should also be formulated that should be optimized in the final implementation of the system.

Mathematical models and algebra should be used to represent the specifications because these are above the syntactic constraints of a language. They also yield to rigorous verification. Even the mathematical models are partitioned into various domains each with its own specific properties and execution models. Since specification models will be heterogeneous, all the models should be unified in a framework. This framework should allow understanding of relations among the models and composition rules. UML can be used as a standard expression mechanism. UML can be used to specify a platform based layered design.

5.2 Refinement and Decomposition:

The implementation should proceed in well-defined stages. The main issue to resolve here is the definition of refinement in the appropriate mathematical framework and the proofs that the original properties are preserved. The system should be decomposed into smaller pieces. Successive refinement, decomposition and composition are the steps to move towards implementation.

5.3 Analysis:

Tools should be present to evaluate the intermediate results with respect to constraints. There is the danger of otherwise of going deep down the implementation path before discovery of errors. In the case of embedded systems, testing after deployment is an impossible scenario since it may lead to disastrous consequences. The major issue to be resolved here is finding appropriate models at this level of abstraction that carry enough details about the physical implementation.

5.4 Target platform definition:

Since most embedded systems are defined to map onto a target platform, it is necessary to find the right specification form and notations to describe the target platform. A UML based description of a target platform can become the target of refinement and analysis.

5.5 Mapping:

This process associates portions of the embedded system refined specification with specific implementation vehicles contained within the target platform.

5.6 Verification:

If a formal specification method is used, verifying the design correctness will be easier and more rigorous.

6. CONCLUSION:

Since the concept of ESW is radically different from traditional software, software engineering paradigms developed so far fail in the embedded systems domain. There is a need to develop new design paradigms that facilitate building complex embedded systems. While there is an improvement in ESW design by focusing on UML based platform definitions and object oriented concepts, the crisis in ESW can be resolved only by taking a high level view of the problem. This paper dealt with approaches to ESW design that involved moving ESW upper in the layers of abstraction while linking it firmly to the underlying hardware. While improvement in design paradigms such as OOD, UML etc...help during implementation, a holistic approach dealing with improving the development process itself will produce better ESW.

REFERENCES:

[1] A.Sangiovanni-Vincentelli and A.Ferrari, “System Design- Traditional Concepts and New Paradigms”, ICCD 99, Austin, October, 1999, 2-12.

[2] G.Martin, L.Lavagno,J.Louis-Guerin, “Embedded UML: a merger of real-time UML and co-design”, CODES 2001, Copenhagen, April 2001, 23-28.

[3] Marco Sgroi,Luciano Lavagno, Alberto Sangiovanni-Vincentelli,. Formal Models for Embedded System Design. IEEE Design & Test of Computers, 17(2), June,2000,14-27.

[4]K.Keutzer, S.Malik, A.R.Newton, J.Rabaey and A. Sangiovanni-Vincentelli. System Level Design: Orthogonalization of Concerns and Platform-Based Design, IEEE Trans on CAD of Integrated Circuits and Systems, 19(12), December 2000, 1523-1543.

[5] Edward A. Lee, “Embedded Software, Advances in Computers, Vol.56, London, 2002.

[6] Rong Chen,Marco Sgroi, Grant Martin, Luciano Lavagno, Alberto Sangiovanni-Vincentelli, Jan Rabaey, “Embedded System Design using UML and Platforms”

[7] Alberto Sangiovanni-Vincentelli, Grant Martin, “A Vision for Embedded Software”, CASES 2001, Atlanta, Georgia, November 2001, 16-17

[8]Rolf Ernst, “Codesign of Embedded Systems: Status and Trends”, IEEE Design and Test of Computers, April-June 1998.

1