EMBEDDED SYSTEM DESIGN PROCESS:
This section provides an overview of the embedded system design process aimed at two
objectives. First, it will give us an introduction to the various steps in embedded system design
before we delve into them in more detail. Second, it will allow us to consider the design
methodology itself. A design methodology is important for three reasons. First, it allows us to
keep a scorecard on a design to ensure that we have done everything we need to do, such as
optimizing performance or performing functional tests. Second, it allows us to develop
computer-aided design tools. Developing a single program that takes in a concept for an
embedded system and emits a completed design would be a daunting task, but by first breaking
the process into manageable steps, we can work on automating (or at least semi automating) the
steps one at a time. Third, a design methodology makes it much easier for members of a design
team to communicate.
The below Figure summarizes the major steps in the embedded system design process.
In this top–down view, we start with the system requirements.
Requirements:
Clearly, before we design a system, we must know what we are designing. The initial stages of
the design process capture this information for use in creating the architecture and components.
We generally proceed in two phases: First, we gather an informal description from the customers
known as requirements, and we refine the requirements into a specification that contains enough
information to begin designing the system architecture.
Requirements may be functional or nonfunctional. We must of
course capture the basic functions of the embedded system, but
functional description is often not sufficient. Typical nonfunctional
requirements include:
■ Performance: The speed of the system is often a major consideration
both for the usability of the system and for its ultimate cost. As we
have noted, performance may be a combination of soft performance
metrics such as approximate time to perform a user-level function
and hard deadlines by which a particular operation must be
completed.
■ Cost: The target cost or purchase price for the system is almost
always a consideration. Cost typically has two major components:
manufacturing cost includes the cost of components and assembly;
nonrecurring engineering (NRE) costs include the personnel and
other costs of designing the system.
■ Physical size and weight: The physical aspects of the final system
can vary greatly depending upon the application. An industrial
control system for an assembly line may be designed to fit into a
standard-size rack with no strict limitations on weight. A handheld
device typically has tight requirements on both size and weight that
can ripple through the entire system design.
■ Power consumption: Power, of course, is important in battery-
powered systems and is often important in other applications as well.
Power can be specified in the requirements stage in terms of battery
life—the customer is unlikely to be able to describe the allowable
wattage.
A sample requirement form that can be filled out at the start of the
project. We can use the form as a checklist in considering the basic
characteristics of the system. Let’s consider the entries in the form:
■ Name: This is simple but helpful. Giving a name to the project not
only simplifies talking about it to other people but can also
crystallize the purpose of the machine.
■ Purpose: This should be a brief one- or two-line description of what
the system is supposed to do. If you can’t describe the essence of
your system in one or two lines, chances are that you don’t
understand it well enough.
■ Inputs and outputs: These two entries are more complex than they
seem. The inputs and outputs to the system encompass a wealth of
detail:
— Types of data: Analog electronic signals? Digital data? Mechanical inputs?
— Data characteristics: Periodically
arriving data, such as digital audio
samples? Occasional user inputs? How
many bits per data element?
— Types of I/O devices: Buttons? Analog/digital converters? Video displays?
■ Functions: This is a more detailed description of what the system
does. A good way to approach this is to work from the inputs to the
outputs: When the system receives an input, what does it do? How
do user interface inputs affect these functions? How do different
functions interact? Performance: Many embedded computing
systems spend at least some time controlling physical devices or
processing data coming from the physical world. In most of
these cases, the computations must be performed within a certain
time frame. It is essential that the performance requirements be
identified early
since they must be carefully measured during implementation to
ensure that the system works properly.
■ Manufacturing cost: This includes primarily the cost of the
hardware components. Even if you don’t know exactly how much
you can afford to spend on system components, you should have
some idea of the eventual cost range. Cost has a substantial influence
on architecture: A machine that is meant to
sell at $10 most likely has a very different internal structure than a $100 system.
■ Power: Similarly, you may have only a rough idea of how much
power the system can consume, but a little information can go a
long way. Typically, the most important decision is whether the
machine will be battery powered or plugged into the wall. Battery-
powered machines must be much more careful about how they
spend energy.
■ Physical size and weight: You should give some indication of the
physical size of the system to help guide certain architectural
decisions. A desktop machine has much more flexibility in the
components used than, for example, a lapel mounted voice recorder.
GPS MODULE:
REQUIREMENTS FORM OF GPS MOVING MAP MODULE:
Name: GPS moving map
Purpose: Consumer-grade moving map for driving use Inputs : Power button, two control buttons
Outputs: Back-lit LCD display 400 _ 600
Functions: Uses 5-receiver GPS system; three user-selectable resolutions; always displays
current latitude and longitude
Performance: Updates screen within 0.25 seconds upon movement Manufacturing cost: $30
Power: 100mW
Physical size and weight: No more than 2” _ 6,” 12 ounces
Specification
The specification is more precise—it serves as the contract between the customer and the
architects. As such, the specification must be carefully written so that it accurately reflects the
customer’s requirements and does so in a way that can be clearly followed during design.
The specification should be understandable enough so that someone can verify that it meets
system requirements and overall expectations of the customer.
A specification of the GPS system would include several components:
▪ Data received from the GPS satellite constellation.
▪ Map data.
▪ User interface.
▪ Operations that must be performed to satisfy customer requests.
▪ Background actions required to keep the system running, such as
operating the GPS receiver.
Architecture Design
The specification does not say how the system does things, only what the system does.
Describing how the system implements those functions is the purpose of the architecture. The
architecture is a plan for the overall structure of the system that will be used later to design the
components that make up the architecture. The creation of the architecture is the first phase of
what many designers think of as design.
This block diagram is still quite abstract—we have not yet specified which operations will be
performed by software running on a CPU, what will be done by special-purpose hardware, and
so on. The diagram does, however, go a long way toward describing how to implement the
functions described in the specification. We clearly see, for example, that we need to search the
topographic database and to render (i.e., draw) the results for the display. We have chosen to
separate those functions so that we can potentially do them in parallel—performing rendering
separately from searching the database may help us update the screen more fluidly.
FIG: BLOCK DIAGRAM FOR THE MOVING MAP
The hardware block diagram clearly shows that we have one central CPU surrounded by memory
and I/O devices. In particular, we have chosen to use two memories: a frame buffer for the pixels
to be displayed and a separate program/data memory for general use by the CPU. The software
block diagram fairly closely follows the system block diagram, but we have added a timer to
control when we read the buttons on the user interface and render data onto the screen. To have a
truly complete architectural description, we require more detail, such as where units in the
software block diagram will be executed in the hardware block diagram and when operations
will be performed in time.
Fig: Hardware and software architectures for the moving map
The architectural description tells us what components we need. The component design effort
builds those components in conformance to the architecture and specification. The components
will in general include both hardware—FPGAs, boards, and so on—and software modules. Some
of the components will be ready-made. The CPU, for example, will be a standard component in
almost all cases, as will memory chips and many other components. In the moving map, the GPS
receiver is a good example of a specialized component that will nonetheless be a predesigned,
standard component. We can also make use of standard software modules.
System Integration:
Only after the components are built do we have the satisfaction of putting them together and
seeing a working system. Of course, this phase usually consists of a lot more than just plugging
everything together and standing back. Bugs are typically found during system integration, and
good planning can help us find the bugs quickly. By building up the system in phases and
running properly chosen tests, we can often find bugs more easily. If we debug only a few
modules at a time, we are more likely to uncover the simple bugs and able to easily recognize
them. Only by fixing the simple bugs early will we be able to uncover the more complex or
obscure bugs that can be identified only by giving the system a hard workout
Characteristics of Embedded systems:
Embedded systems possess certain specific characteristics and these are unique to each
Embedded system.
1. Application and domain specific
2. Reactive and Real Time
3. Operates in harsh environments
4. Distributed
5. Small Size and weight
6. Power concerns
7. Single-functioned
8. Complex functionality
9. Tightly-constrained
10. Safety-critical
1. Application and Domain Specific: -
• Each E.S has certain functions to perform and they are developed in such a manner to
do the intended functions only.
• They cannot be used for any other purpose.
Examples – The embedded control units of the microwave oven cannot be replaced
with AC‟S embedded control unit because the embedded control units of microwave
oven and AC are specifically designed to perform certain specific tasks.
2. Reactive and Real Time: -
• E.S are in constant interaction with the real world through sensors and
user-defined input devices which are connected to the input port of the
system.
• Any changes in the real world are captured by the sensors or input
devices in real time and the control algorithm running inside the unit
reacts in a designed manner to bring the controlled output variables to
the desired level.
• E.S produce changes in output in response to the changes in the input,
so they are referred as reactive systems.
• Real Time system operation means the timing behavior of the system
should be deterministic ie the system should respond to requests in a
known amount of time.
Example – E.S which are mission critical like flight control systems,
Antilock Brake Systems (ABS) etc. are Real Time systems.
3. Operates in Harsh Environment: –
• The design of E.S should take care of the operating conditions of the
area where the system is going to implement.
Example – If the system needs to be deployed in a high temperature
zone, then all the components used in the system should be of high
temperature grade.
Also, proper shock absorption techniques should be provided to systems
which are going to be commissioned in places subject to high shock.
4. Distributed: –
• It means that embedded systems may be a part of a larger system.
• Many numbers of such distributed embedded systems form a single
large embedded control unit.
Example – Automatic vending machine. It contains a card reader, a
vending unit etc. Each of them is independent embedded units but they
work together to perform the overall vending function.
5. Small Size and Weight: -
• Product aesthetics (size, weight, shape, style, etc.) is an important factor
in choosing a product.
• It is convenient to handle a compact device than a bulky product.
6. Power Concerns: -
• Power management is another important factor that needs to be
considered in designing embedded systems.
• E.S should be designed in such a way as to minimize the heat dissipation
by the system.
7. Single-functioned: - Dedicated to perform a single function
8. Complex functionality: - We have to run sophisticated algorithms or
multiple algorithms in some applications.
9. Tightly-constrained: - Low cost, low power, small, fast, etc.
10. Safety-critical: - Must not endanger human life and the environment
Quality Attributes of Embedded Systems:
Quality attributes are the non-functional requirements that need to be documented properly in any
system design.
Quality attributes can be classified as
i. Operational quality attributes
ii. Non-operational quality attributes.
Operational Quality Attributes: The operational quality attributes represent the relevant quality
attributes related to the embedded system when it is in the operational mode or online mode.
Operational Quality Attributes are:
• Response: - It is the measure of quickness of the system. It tells how fast the system is
tracking the changes in input variables. Most of the E.S demands fast response which
should be almost real time. Example – Flight control application.
• Throughput: - It deals with the efficiency of a system. It can be defined as the rate of
production or operation of a defined process over a stated period of time. The rates can be
expressed in terms of products, batches produced or any other meaningful measurements.
Example – In case of card reader throughput means how many transactions the reader
can perform in a minute or in an hour or in a day. Throughput is generally measured in
terms of “Benchmark”. A Benchmark is a reference point by which something can be
measured
• Reliability: - It is a measure of how much we can rely upon the proper functioning of the
system. The Mean Time Between Failure (MTBF) and Mean Time To Repair (MTTR) are
the terms used in determining system reliability. MTBF gives the frequency of failures in
hours/weeks/months. MTTR specifies how long the system is allowed to be out of order
following a failure. For embedded system with critical application need, it should be of
the order of minutes.
• Maintainability: - It deals with support and maintenance to the end user or client in case
of technical issues and product failure or on the basis of a routine system checkup.
Reliability and maintainability are complementary to each other. A more reliable system
means a system with less corrective maintainability requirements and vice versa.
Maintainability can be broadly classified into two categories
➢ Scheduled or Periodic maintenance (Preventive maintenance)
➢ Corrective maintenance to unexpected failures
• Security: - Confidentiality, Integrity and availability are the three major measures of
information security. Confidentiality deals with protection of data and application from
unauthorized disclosure. Integrity deals with the protection of data and application from
unauthorized modification. Availability deals with protection of data and application from
unauthorized users.
• Safety: - Safety deals with the possible damages that can happen to the operator, public
and the environment due to the breakdown of an Embedded System. The breakdown of
an embedded system may occur due to a hardware failure or a firmware failure. Safety
analysis is a must in product engineering to evaluate the anticipated damages and
determine the best course of action to bring down the consequences of damage to an
acceptable level.
Non-Operational Quality Attributes: The quality attributes that needs to be addressed for the
product not on the basis of operational aspects are grouped under this category.
• Testability and Debug-ability: - Testability deals with how easily one can test the
design, application and by which means it can be done. For an E.S testability is
applicable to both the embedded hardware and firmware. Embedded hardware testing
ensures that the peripherals and total hardware functions in the desired manner, whereas
firmware testing ensures that the firmware is functioning in the expected way.
Debug-ability is a means of debugging the product from unexpected behavior in the
system. Debug-ability is two level process;
[Link] level: It is used for finding the issues created by hardware problems.
[Link] level: It is employed for finding the errors created by the flaws in the
software.
• Evolvability: - It is a term which is closely related to Biology. It is referred as the non-
heritable variation. For an embedded system evolvability refers to the ease with which the
embedded product can be modified to take advantage of new firmware or hardware
technologies.
• Portability: - It is the measure of system independence. An embedded product is said to
be portable if the product is capable of functioning in various environments, target
processors and embedded operating systems. “Porting” represents the migration of
embedded firmware written for one target processor to a different target processor.
• Time-to-Prototype and Market: - It is the time elapsed between the conceptualization
of a product and the time at which the product is ready for selling. The commercial
embedded product market is highly competitive and time to market the product is critical
factor in the success of commercial embedded product. There may be multiple players in
embedded industry who develop products of the same category (like mobile phone).
• Per Unit Cost and Revenue: - Cost is a factor which is closely monitored by both end
user and product manufacturer. Cost is highly sensitive factor for commercial products
Any failure to position the cost of a commercial product at a nominal rate may lead to the
failure of the product in the market. Proper market study and cost benefit analysis should
be carried out before taking a decision on the per-unit cost of the embedded product. The
ultimate aim of the product is to generate marginal profit so the budget and total cost
should be properly balanced to provide a marginal profit.