Embedded System Design

System design is the process of converting customer

requirements into a working system.
From formal specification, we will partition the
system to develop a functional design. Then does the
process of mapping into an architectural design.
The product life cycle is a descriptive presentation.
It breaks the development process into series of
interrelated activities. The steps are organized
according to process model called Life cycle.

1
 The Embedded System lifecycle
Embedded System lifecycle: series of steps /
phases, through which Embedded System is produced
can take months or years to complete

goals of each phase:

mark out a clear set of steps to perform
produce a tangible document or item
allow for review of work
specify actions to perform in the next phase

common observation: The later a problem is found in

Embedded System , the more costly it is to fix
2
 Lifecycle phases
standard phases
1. Requirements Analysis & Specification
2. Design
3. Implementation, Integration
4. Testing, Profiling, Quality Assurance
5. Operation and Maintenance

other possible phases

risk assessment: examining what actions are critical and
performing them first (part of Spiral model)
prototyping: making a quick version of the product and
using it to guide design decisions
3
 Each Phase has an Output

Phase Output
Requirements analysis Embedded System
Requirements
Specification
Design
Design Document,
Implementation Design Classes
Code
Test
Test Report,
Change Requests
 One view of Life cycle phases

Requirements System Detail Implemen-

Analysis Testing
Elicitation Design Design tation

Implemented
By
Expressed in Structured By Realized By Verified
Terms Of
By

Hardware
&Software
?
?
Design Requirement Solution
specification Subsystems Source Test
Document Domain
Code Cases
Objects

5
 Models
Different projects may interpret these phases
differently.

Each particular style is called a Embedded System

Life-Cycle Model

Single-Version Models
Incremental Models
Single-Version with Prototyping
Iterative Models

 Incremental vs. Iterative

These sound similar, and sometimes are equated.
Subtle difference:

Incremental: add to the product at each phase

Iterative: re-do the product at each phase

Some of the models could be used either way.

 Example: Building a House

Incremental: Start with a modest house,

keep adding rooms and upgrades to it.

Iterative: On each iteration, the house is

re-designed and built a new.

Big Difference: One can live in the incremental

house the entire time! One has to move to a new
iterative house.
 Some Life cycle models
Several models for developing software have
been attempted:
code-and-fix: write some code, debug it, repeat
until finished
evolutionary: build initial requirement spec, write
it, then "evolve" the spec and code as needed
waterfall: perform the standard phases
(requirements, design, code, test) in sequence
rapid prototyping: write an initial "throwaway"
version of the product, then design, code, test
spiral: assess risks at each step, and do the most
critical action immediately
9
 code-and-fix model

Code First
Version

Modify until
Client is satisfied

Operations Mode

Retirement

10
 Problems with code-and-fix
What are some reasons not to use the code-
and-fix model?

code becomes expensive to fix (bugs are not

found until late in the process)
code didn't match user's needs (no
requirements phase!)
code was not planned for modification, not
flexible
11
 The Rapid Prototyping Model
Requirements gathering
Quick design
Prototype building
Prototype evaluation by customers
Prototype may be refined
Prototype thrown away and software developed
using formal process.
It is incremental model.
 Rapid prototyping model

Req. Change
Rapid Prototype

Verify
Redesign

Verify
Re-implementation

Test

Operations

Retirement

13
 Advantages of Rapid Prototyping Model

Users/customers own requirements

Instills customer confidence that the
right product is being built
Provides a good way to determine
requirements when there is uncertainty
about what is needed
 Disadvantages of Rapid Prototyping

Prototypes are not always thrown away

they often become the products or
fundamental parts of the products
Requires lots of customer involvement
which isnt always possible
Validation may be difficult because the
requirements may not be well
documented
 Waterfall model (Royce, 1970)

Req. Change
Requirements

Verify
Preliminary Design

Verify
Detailed Design

Test

Implementation

Retirement

16
 Waterfall / Prototyping issues
The waterfall models (with or without
prototyping) are perhaps the most common
model for project development
What are some positives and negatives about
this method?
+ formal, standard, has specific phases with clear goals
+ good feedback loops between adjacent phases
- rigid, too linear; not very adaptable to change in the product
- requires a lot of planning up front (not always easy / possible)
- assumes that requirements will be clear and well-understood
17
 Disadvantages of Waterfall Model

Not realistic (doesnt match real projects)

Does not reflect the iterative nature of software
Complete set requirements seldom known at
the beginning of a project
Working software not available until near end
of project
Does not incorporate risk assessment.
V Model
Each phase has corresponding test or validation counterpart

Requirements Performance
Analysis / Test
Specification

System Design Integration

Test

Detail Design Unit Testing

Implementation
 V Model
V model is similar to waterfall except that it has
more emphasis on testing activities initially
instead of later stage.
Every stage associates with test or validation at
the same level.
Each development activity builds a detailed
model and each verification step tests a more
complete implementation at that phase.

20
The Spiral Model

Planning
Risk Analysis
Development
Evaluation
Spiral model (Boehm)

22
 Advantages of the Spiral Model

Incorporates the iterative nature of software

development
Incorporates all the advantages of both the
waterfall model and prototyping model
 Another view of spiral model
Risk Assessment
Req. Change
Requirements
Risk Assessment
Verify
Design
Risk Assessment
Verify
Implementation

Test
Adds a Risk Analysis
step to each phase
Operations

(phases may not be

completed in this order Retirement
any more!)
24
 Disadvantages of the Spiral Model

Requires expertise in risk analysis.

Each spiral addresses major risks that have
been identified. After all risks are addressed,
the spiral model terminates.
Its philosophy is to start small, explore the
risks, develop plan to deal with risk and go for
next iteration.
It is somewhat complicated and not well
understood
 Spiral model problems
What are some positives and negatives about
this method?
+ focuses attention on reuse
+ accommodates changes, growth
+ eliminates errors and unattractive choices early
+ It provides several opportunities for risk assessment and
customer involvement.
- It is difficult to manage.
- relying on developers to have risk-assessment expertise
- Does not keep all developers occupied during all phases.
26
 Problem solving
We begin with set of requirements usually stated in
text form.
Good system designers follow five steps:
Requirements Definition- It is to capture formal
description of the complete system from customers
point of view.
System specifications It is in terms of external
entities, their descriptions, whether it is data, event, a
state variable or message.
Responsibilities- What activity is supposed to perform?
relationsship, and safety of those entities.
27
 System specifications vs. Requirements

Initially it seems same, but not.

System requirements comes from marketing or sales
department, and they represent customer needs. It is
intended to describe what a system must do.
The system design specification is generated by
engineering as answer how to implement the
requirements.

28
 Functional Design
The purpose is to find an appropriate internal
functional architecture for the system. Through this
analysis, a somewhat loose understanding can be
converted into precise description.
The functional design should be written to be
understand in application domain and by those who
will do Hardware and software development.
First functional decomposition is carried out by
identifying events or variables. Successive refinements
is made such that elementary or leaf function is
obtained. It is called functional model.
29
 Architectural Design
In executing an architectural design, the goal is to
select most appropriate solution to the original
problem.
It also gives choice of best suited hardware- software
partitioning and allocation of functionality.
The internal organization depends on many
components and interconnections.
The architectural model describes the physical
architecture of the system based on real components
such as microprocessors, programmable memories,
analog and digital components.
30
 Both functional and architectural model are
necessary to be able to represent and build,
evaluate hardware/ software system.

31