Read an Excerpt
Software Engineering for Embedded Systems
Methods, Practical Techniques, and Applications
By Robert Oshana, Mark Kraeling Elsevier
Copyright © 2013 Elsevier Inc.
All rights reserved.
ISBN: 978-0-12-415941-9
CHAPTER 1
Software Engineering of Embedded and Real-Time Systems
Robert Oshana
Chapter Outline
Software engineering 1
Embedded systems 7
Embedded systems are reactive systems 9
Real-time systems 12
Types of real-time systems — soft and hard 12
Differences between real-time and time-shared systems 14
Examples of hard real-time 15
Based on signal sample, time to perform actions before next sample arrives 15
Hard real-time systems 15
Real-time event characteristics 17
Real-time event categories 17
Efficient execution and the execution environment 17
Efficiency overview 17
Resource management 18
Challenges in real-time system design 18
Response time 19
Recovering from failures 20
The embedded system software build process 21
Distributed and multi-processor architectures 23
Software for embedded systems 24
Super loop architecture 24
Power-save super loop 25
Window lift embedded design 26
Hardware abstraction layers (HAL) for embedded systems 27
Summary 30
Software engineering
Over the past ten years or so, the world of computing has moved from large, static, desktop machines to small, mobile, and embedded devices. The methods, techniques, and tools for developing software systems that were successfully applied in the former scenario are not as readily applicable in the latter. Software systems running on networks of mobile, embedded devices must exhibit properties that are not always required of more traditional systems:
• near-optimal performance
• robustness
• distribution
• dynamism
• mobility.
This book will examine the key properties of software systems in the embedded, resource-constrained, mobile, and highly distributed world. We will assess the applicability of mainstream software engineering methods and techniques (e.g., software design, component-based development, software architecture, system integration and test) to this domain.
One of the differences in software engineering for embedded systems is the additional knowledge the engineer has of electrical power and electronics; physical interfacing of digital and analog electronics with the computer; and software design for embedded systems and digital signal processors (DSP).
Over 95% of software systems are actually embedded. Consider the devices you use at home on a daily basis;
• cell phone, iPod, microwave
• satellite receiver, cable box
• car engine control unit
• DVD player.
So what do we mean by software engineering for embedded systems? Let's look at this in the context of engineering in general. Engineering is defined as the application of scientific principles and methods to the construction of useful structures and machines. This includes disciplines such as:
• mechanical engineering
• civil engineering
• chemical engineering
• electrical engineering
• nuclear engineering
• aeronautical engineering.
Software engineering is a term that is 35 years old, originating at a NATO conference in Garmisch, Germany, October 7–11, 1968. Computer science is the scientific basis and many aspects have been made systematic in software engineering:
• methods/methodologies/techniques
• languages
• tools
• processes.
We will explore all of these in this book.
The basic tenets of software engineering include:
• development of software systems whose size/complexity warrants team(s) of engineers (or as David Parnas puts it, "multi-person construction of multi-version software");
• scope, which we will focus on the study of software process, development principles, techniques, and notations;
• goal, in our case the production of quality software, delivered on time, within budget, satisfying customers' requirements and users' needs.
With this come the ever-present difficulties of software engineering that still exist today:
• there are relatively few guiding scientific principles;
• there are few universally applicable methods;
• software engineering is as much managerial/psychological/sociological as it is technological.
There difficulties exist because software engineering is a unique form of engineering:
• software is malleable;
• software construction is human-intensive;
• software is intangible;
• software problems are unprecedentedly complex;
• software directly depends upon the hardware;
• software solutions require unusual rigor;
• software has discontinuous operational nature.
Software engineering is not the same as software programming. Software programming usually involves a single developer developing "toy" applications and involves a relatively short lifespan. With programming, there is a single or few stakeholders and the project is mostly one-of-a-kind systems built from scratch with minimal maintenance.
Software engineering on the other hand involves teams of developers with multiple roles building complex systems with an indefinite lifespan. There are numerous stakeholders, families of systems, a heavy emphasis on reuse to amortize costs and a maintenance phase that accounts for over 60% of overall development costs.
There are economic and management aspects of software engineering. Software production includes the development and maintenance (evolution) of the system. Maintenance costs are the majority of all development costs. Quicker development is not always preferable. In other words, higher up-front costs may defray downstream costs. Poorly designed and implemented software is a critical cost factor. In this book we will focus on software engineering of embedded systems, not programming embedded systems.
Embedded software development uses the same software development models as other forms of software development, including the Waterfall model (Figure 1.1), the Spiral model (Figure 1.2) and the Agile model (Figure 1.3). The benefits and limitations of each of these models are well documented so we will review these here. We will, however, spend more time later in this book on Agile development, as this approach is well suited to the changing, dynamic nature of embedded systems.
The key software development phases for embedded systems are briefly summarized below.
1. Problem definition: in this phase we determine exactly what the customer and user want. This may include the development of a contract with the customer, depending on what type of product is being developed. This goal of this phase is to specify what the software product is to do. Difficulties include the client asking for the wrong product, the client being computer/software illiterate, which limits the effectiveness of this phase, and specifications that are ambiguous, inconsistent, and incomplete.
2. Architecture/design: architecture is concerned with the selection of architectural elements, their interactions, and the constraints on those elements and their interactions necessary to provide a framework in which to satisfy the requirements and serve as a basis for the design. Design is concerned with the modularization and detailed interfaces of the design elements, their algorithms and procedures, and the data types needed to support the architecture and to satisfy the requirements. During the architecture and design phases, the system is decomposed into software modules with interfaces. During design the software team develops module specifications (algorithms, data types), maintains a record of design decisions and traceability, and specifies how the software product is to do its tasks. The primary difficulties during this phase include miscommunication between module designers and developing a design that may be inconsistent, incomplete, ambiguous.
3. Implementation: during this phase the development team implements the modules and components and verify that they meet their specifications. Modules are combined according to the design. The implementation specifies how the software product does its tasks. Some of the key difficulties include module interaction errors and the order of integration that may influence quality and productivity.
More and more development of software for embedded systems is moving towards component-based development. This type of development is generally applicable for components of a reasonable size and reuse across systems, which is a growing trend in embedded systems. Developers ensure these components are adaptable to varying contexts and extend the idea beyond code to other development artifacts as well. This approach changes the equation from "Integration, Then Deployment" to "Deployment, Then Integration".
There are different makes and models of software components:
• third-party software components
• plug-ins / add-ins
• frameworks
• open systems
• distributed object infrastructures
• compound documents
• legacy systems.
4. Verification and validation (V&V): there are several forms of V&V and there is a dedicated chapter on this topic. One form is "analysis". Analysis can be in the form of static, scientific, formal verification, and informal reviews and walkthroughs. Testing is a more dynamic form of V&V. This form of testing comes in the form of white box (we have access to the code) and black box (no access to the source code). Testing can be structural as well as behavioral. There are the standard issues of test adequacy but we will defer this discussion to later when we dedicate a chapter to this topic.
As we progress through this book, we will continue to focus on the foundational software engineering principles (Figure 1.4);
• rigor and formality
• separation of concerns
• modularity and decomposition
• abstraction
• anticipation of change
• generality
• incrementality
• scalability
• compositionality
• heterogeneity
• from principles to tools.
Embedded systems
So what is an embedded system? There are many answers to this question. Some define an embedded system simply as "a computer whose end function is not to be a computer". If we follow this definition, then automobile anti-lock braking systems, digital cameras, household appliances, and televisions are embedded systems because they contain computers but aren't intended to be computers. Conversely, the laptop computer I'm using to write this chapter is not an embedded system because it contains a computer that is intended to be a computer (see Bill Gatliff's article "There's no such thing as an Embedded System" on embedded.com).
(Continues...)
Excerpted from Software Engineering for Embedded Systems by Robert Oshana, Mark Kraeling. Copyright © 2013 Elsevier Inc.. Excerpted by permission of Elsevier.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
