Embedded System

Design
BITS Pilani Prof. Manoj S Kakade
Dept of EEE
Pilani Campus
 BITS Pilani
Pilani Campus

ESZG512/MELZG526/SEZG516
Embedded System Design
Contact Session 6
 Small Scale Embedded System Design
 Understanding Complete Embedded System Design
 Procedure starting from System Requirements to
Final Design

3 BITS Pilani, Deemed to be University under Section 3, UGC Act

 THE EMBEDDED SYSTEM DESIGN PROCESS
 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.
 By defining the overall process, team members can more easily understand
what they are supposed to do, what they should receive from other team
members at certain times, and what they are to hand off when they
complete their assigned steps.

4 BITS Pilani, Deemed to be University under Section 3, UGC Act

THE EMBEDDED SYSTEM DESIGN PROCESS
 In top–down view , we start with the system
requirements.
 Specification, we create a more detailed
description of what we want. But the
specification states only how the system behaves,
not how it is built.
 The details of the system’s internals begin to take
shape when we develop the architecture, which
gives the system structure in terms of large
components.
 Once we know the components we need, we can
design those components, including both software
modules and any specialized hardware we need.
 Based on those components , we can finally build
a complete system.

5 BITS Pilani, Deemed to be University under Section 3, UGC Act

THE EMBEDDED SYSTEM DESIGN PROCESS
 We need bottom–up design because we do not
have perfect insight into how later stages of the
design process will turn out.
 Decisions at one stage of design are based upon
estimates of what will happen later:
 How fast can we make a particular function run?
 How much memory will we need?
 How much system bus capacity do we need?
 If our estimates are inadequate, we may have to
backtrack and amend our original decisions to
take the new facts into account.
 In general, the less experience we have with the
design of similar systems, the more we will have
to rely on bottom-up design information to help
us refine the system.

6 BITS Pilani, Deemed to be University under Section 3, UGC Act

 THE EMBEDDED SYSTEM DESIGN PROCESS
 We also need to consider the major goals of the design:
 manufacturing cost
 performance (both overall speed and deadlines)
 power consumption

 At each step in the design, we add detail:

 We must analyze the design at each step to determine how we
can meet the specifications.
 We must then refine the design to add detail.
 And we must verify the design to ensure that it still meets all
system goals, such as cost, speed, and so on.

7 BITS Pilani, Deemed to be University under Section 3, UGC Act

 Requirements
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 non functional.
 We must of course capture the basic functions of the
embedded system, but functional description is often not
sufficient.

8 BITS Pilani, Deemed to be University under Section 3, UGC Act

 Requirements
Typical non functional 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.
 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

9 BITS Pilani, Deemed to be University under Section 3, UGC Act

 Requirements
Typical nonfunctional requirements include:-
 Physical size and weight: The physical aspects of the final
system can vary greatly depending upon the application.
 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.

10 BITS Pilani, Deemed to be University under Section 3, UGC Act

 Requirements
Sample requirements form.:-
 Name After writing the requirements,
 Purpose you should check them for
internal consistency:
 Inputs  Did you forget to assign a
 Outputs function to an input or output?
 Functions  Did you consider all the
 Performance modes in which you want the
 Manufacturing cost system to operate?
 Did you place an unrealistic
 Power number of features into a
 Physical size and weight battery-powered, low-cost
machine?
11 BITS Pilani, Deemed to be University under Section 3, UGC Act
 Requirements :- Example
Requirements analysis of a GPS moving map
 The moving map is a handheld device that displays for the user a map of the
terrain around the user’s current position; the map display changes as the user
and the map device change position.
 Functionality: This system is designed for highway driving and
similar uses, not nautical or aviation uses that require more
specialized databases and functions. The system should show
major roads and other landmarks available in standard topographic
databases.
 User interface: The screen should have at least 400x600 pixel
resolution. The device should be controlled by no more than three
buttons. A menu system should pop up on the screen when buttons
are pressed to allow the user to make selections to control the
system.
12 BITS Pilani, Deemed to be University under Section 3, UGC Act
 Requirements :- Example
Requirements analysis of a GPS moving map
 Performance: The map should scroll smoothly. Upon power-up,
a display should take no more than one second to appear, and the
system should be able to verify its position and display the
current map within 15 s.
 Cost: The selling cost (street price) of the unit should be no
more than $100.
 Physical size and weight: The device should fit comfortably in
the palm of the hand.
 Power consumption: The device should run for at least eight
hours on four AA batteries.
 Note that many of these requirements are not specified in engineering units—
for example, physical size is measured relative to a hand, not in centimeters.
13 BITS Pilani, Deemed to be University under Section 3, UGC Act
 Requirements :- Example
Requirements analysis of a GPS moving map
 This chart adds some requirements in engineering terms that will be of use to
the designers
 Name:- GPS moving map
 Purpose :- Consumer-grade moving map for driving use
 Inputs :- Power button, two control buttons
 Outputs :- Back-lit LCD display 400 x 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

14 BITS Pilani, Deemed to be University under Section 3, UGC Act

 Specifications
 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.
 It should also be unambiguous enough that designers know
what they need to build.

15 BITS Pilani, Deemed to be University under Section 3, UGC Act

 Specifications
 Designers can run into several different types of problems
caused by unclear specifications.
 If the behavior of some feature in a particular situation is
unclear from the specification, the designer may implement the
wrong functionality.
 If global characteristics of the specification are wrong or
incomplete, the overall system architecture derived from the
specification may be inadequate to meet the needs of
implementation.

16 BITS Pilani, Deemed to be University under Section 3, UGC Act

 Specifications
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.

17 BITS Pilani, Deemed to be University under Section 3, UGC Act

 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.

18 BITS Pilani, Deemed to be University under Section 3, UGC Act

 Architecture Design
 System architecture in the form of a block diagram that shows
major operations and data flows among them.

19 BITS Pilani, Deemed to be University under Section 3, UGC Act

 Architecture Design
 The 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.

20 BITS Pilani, Deemed to be University under Section 3, UGC Act

 Architecture Design
 Only after we have designed an initial architecture that is not biased toward
too many implementation details should we refine that system block
diagram into two block diagrams: one for hardware and another for
software.

21 BITS Pilani, Deemed to be University under Section 3, UGC Act

 Architecture Design
 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.

22 BITS Pilani, Deemed to be University under Section 3, UGC Act

 Architecture Design
 Architectural descriptions must be designed to satisfy both
functional and nonfunctional requirements.
 Not only must all the required functions be present, but we
must meet cost, speed, power, and other nonfunctional
constraints.
 Starting out with a system architecture and refining that to
hardware and software architectures is one good way to ensure
that we meet all specifications.
 We can concentrate on the functional elements in the system
block diagram, and then consider the nonfunctional constraints
when creating the hardware and software architectures.

23 BITS Pilani, Deemed to be University under Section 3, UGC Act

 Designing Hardware and Software Components
 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, will be a
standard component in almost all cases, as will memory chips and
many other components.
 The GPS receiver is a good example of a specialized component that
will nonetheless be a predesigned, standard component.

24 BITS Pilani, Deemed to be University under Section 3, UGC Act

 Designing Hardware and Software Components
 We ca also make use of standard software modules.
 One good example is the topographic database.
 Standard topographic databases exist, and you probably want to use
standard routines to access the database—not only is the data in a
predefined format, but it is highly compressed to save storage.
 Using standard software for these access functions not only saves
our design time, but it may give us a faster implementation for
specialized functions such as the data decompression phase.
 You will have to design some components yourself.
 Even if you are using only standard integrated circuits, you may
have to design the printed circuit board that connects them.
 You will probably have to do a lot of custom programming as well.

25 BITS Pilani, Deemed to be University under Section 3, UGC Act

 Designing Hardware and Software Components
 When creating embedded software modules, you must make use of
your expertise to ensure that the system runs properly in real time
and that it does not take up more memory space than is allowed.
 The power consumption of the GPS software example is particularly
important.
 You may need to be very careful about how you read and write
memory to minimize power—for example, since memory accesses
are a major source of power consumption, memory transactions
must be carefully planned to avoid reading the same data several
times.

26 BITS Pilani, Deemed to be University under Section 3, UGC Act

 System Integration
 Only after the components are built do we have the satisfaction of
putting them together and seeing a working system.
 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.
 We need to ensure during the architectural and component design
phases that we make it as easy as possible to assemble the system in
phases and test functions relatively independently.

27 BITS Pilani, Deemed to be University under Section 3, UGC Act

 Design challenge – optimizing design metrics
 Obvious design goal:
 Construct an implementation with desired functionality
 Key design challenge:
 Simultaneously optimize numerous design metrics
 Design metric
 A measurable feature of a system’s implementation
 Optimizing design metrics is a key challenge

28 BITS Pilani, Deemed to be University under Section 3, UGC Act

 Design challenge – optimizing design metrics
 Common metrics
 Unit cost: the monetary cost of manufacturing each copy of the system, excluding NRE
cost
 NRE cost (Non-Recurring Engineering cost): The one-time monetary cost of designing
the system
 Size: the physical space required by the system
 Performance: the execution time or throughput of the system
 Power: the amount of power consumed by the system
 Flexibility: the ability to change the functionality of the system without incurring heavy
NRE cost
 Time-to-prototype: the time needed to build a working version of the system
 Time-to-market: the time required to develop a system to the point that it can be
released and sold to customers
 Maintainability: the ability to modify the system after its initial release
 Correctness, safety, many more

29 BITS Pilani, Deemed to be University under Section 3, UGC Act

 Design challenge – optimizing design metrics
 Design metric competition -- improving one may worsen others
Power

Performance Size

NRE cost

 Expertise with both software and hardware is needed to optimize

design metrics
 Not just a hardware or software expert, as is common
 A designer must be comfortable with various technologies in
order to choose the best for a given application and constraints

30 BITS Pilani, Deemed to be University under Section 3, UGC Act

 System Specifications
 Online Lake water quality monitoring system
 The system is made-up of a swarm of floating drogues
 Data collected is transferred to a base-station on land

Source: Anupama, K., et al. “Multi-parameter ocean monitoring system using Underwater Wireless Sensor Networks” 31
https://www.nature.com/articles/ncomms14189
BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
Source: https://www.nature.com/articles/ncomms14189
32

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

 System Specifications
 Drogues are free-floating underwater devices that operate
autonomously & collaborate through an acoustic underwater
network
 Buoyancy controlled
 Acoustically tracked
 Equipped with sensors for data collection
 Part of an ad hoc network for relaying data to surface stations
for analysis

Source: Anupama, K., et al. “Multi-parameter ocean monitoring system using Underwater Wireless Sensor Networks”.
https://www.nature.com/articles/ncomms14189 33

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

 System Specifications
Specifications – Drogue Movement
 Buoyancy control - drogues to move to various depths
 Two concentric, syntactic foam cylinders forming inner and
outer sleeves that can slide over each other to significantly
increase or decrease the vehicle’s volume
 Piston is used to create incremental changes in vehicle volume
while fully submerged to produce the small changes in density
necessary for the vehicle to regulate its depth.
 The total change in volume that is possible with a small piston is
±0.4% with 12,000 increments over the entire piston range.
 A geared motor whose shaft is equipped with an optical encoder
rotates a threaded rod that controls the small piston.
Source: Anupama, K., et al. “Multi-parameter ocean monitoring system using Underwater Wireless Sensor Networks” 34
https://www.nature.com/articles/ncomms14189
BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 System Specifications
Specifications – Movement
 Maintaining a given depth requires an algorithm to change the
vehicle’s buoyancy when ambient currents or changes in density
move it vertically.
 PID control algorithm
 These are used to actuate the piston to minimize the difference
between the desired depth and the actual depth, with the goal of
ultimately converging to the target depth.

Source: Anupama, K., et al. “Multi-parameter ocean monitoring system using Underwater Wireless Sensor Networks” 35
https://www.nature.com/articles/ncomms14189
BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
System Specifications
Specifications – Sensors
 Chlorophyll
 Dissolved O2
 pH
 Turbidity
 Temperature
 Salinity

Source: Anupama, K., et al. “Multi-parameter ocean monitoring system using Underwater Wireless Sensor Networks”
36
BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
 System Specifications
Specifications – Communications
• Data collected - transmitted acoustically using a self-organizing
UAN to base station
• Formation& Maintenance of UAN - network protocol stack -
resident in the flash memory- protocol stack is minimalistic

Source: Anupama, K., et al. “Multi-parameter ocean monitoring system using Underwater Wireless Sensor Networks” 37

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

Requirements
Requirements – Sensor Accuracy
 Chlorophyll – 0.5µg/l
 Dissolved O2 – 0.5 % 0 – 100 %
 pH – 1-14 resolution of 0.5
 Turbidity – 0- 50 Nephelometric Turbidity Units (NTU)
 Temperature - -50º C to 50º C accuracy 0.1º C
 Salinity 0 -2 Siemens/cm with accuracy of 0.5%
 TDS (mg/L) ≈Salinity (EC) x 0.55
 Output Preferably in Analog (0-5V) or (0-3.3V)

Source: Anupama, K., et al. “Multi-parameter ocean monitoring system using Underwater Wireless Sensor Networks”
38

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

 Requirements
Requirements Motors
 Lagrangian (current-following) vehicles
 Buoyancy Control
 Bladder Mechanism
 Servo Motor

Source: Anupama, K., et al. “Multi-parameter ocean monitoring system using Underwater Wireless Sensor Networks” 39
https://www.nature.com/articles/ncomms14189
BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
System Block Diagram

Depth Buoyancy
Sensor Control

Protocol
Activate Sensors Timer Stack

Transceiver

Source: Anupama, K., et al. “Multi-parameter ocean monitoring system using Underwater Wireless Sensor Networks”
40

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

Hardware Block Architecture

Sensor CPU

Buoyancy Control
Memory

Timer
Communication Interface

Source: Anupama, K., et al. “Multi-parameter ocean monitoring system using Underwater Wireless Sensor Networks”
41

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

Components: Sensors
Sensors
pH - WQ201 pH Sensors
 Submersible pH measurements
 Fully encapsulated electronics
 Marine grade cable with strain relief
 Stainless steel housing
 Replaceable pH element
 Output: 4-20 mA
 Range: 0-14 pH
 Accuracy: 2% of full scale
 Operating Voltage: 10-30 VDC
Source: http://www.globalw.com/downloads/WQ/WQ201B.pdf
42

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

Components: Sensors
Salinity - WQ-Cond
 0.5% conductivity reading accuracy
 Dual 4-20 mA outputs, temperature and conductivity
 Measurement span from 0 to 2 siemens/cm
 Sensor armor available for harsh environments
 Measure conductivity up to 82 feet depth
 Fully encapsulated electronics

Source:http://www.globalw.com/downloads/WQ/WQ-cond.pdf
43

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

Components: Sensors
Salinity - WQ-Cond
 Conductivity Range:
 0 to 200 µS/cm
 200 to 2000 µS/cm
 2 to 20 mS/cm
 20 to 200 mS/cm
 200 to 2000 mS/cm
 Conductivity Resolution:
 0.1 µS/cm
 1 µS/cm
 0.01 mS/cm
 0.1 mS/cm
 1 mS/cm
 Output: Dual 4-20 mA (Conductivity and Temperature)
Source: http://www.globalw.com/downloads/WQ/WQ-cond.pdf
44

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

Components: Sensors
Dissolved O2 - WQ401
 Fully encapsulated electronics
 Marine grade cable with strain relief
 Stainless steel housing
 Replaceable DO element
 Output: 4-20 mA
 Range: 0-100% Saturation, 0-8 ppm, temperature compensated
to 77°F (25°C)
 Accuracy: ±0.5% of full scale

Source:http://www.globalw.com/products/wq401.html
45

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

 Components: Sensors
Turbidity Sensors – WQ 730
 Simple and convenient to use
 Marine grade cable with strain relief
 Rugged stainless steel and Delrin sensor housing
 Range: Sensor=0-50 NTU and 0-1000 NTU; Meter=0-50 NTU
or 0-1000 NTU selectable
 Accuracy: + 1% of full scale
 Meter Resolution: 12 bit
 Output: 4-20mA

Source: http://www.globalw.com/products/turbidity.html 46

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

Components: Sensors
Temperature – WQ 101
 Fully encapsulated electronics
 Marine grade cable with strain relief
 Stainless steel housing
 Output: 4-20 mA
 Range: -58 to +122° F (-50 to +50°C)
 Accuracy: ±0.2°F or ±0.1°C

Source: http://www.globalw.com/products/wq101.html
47

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

Components: Sensors
Flourometers - for studies needing chlorophyll concentration data.
 Output Voltage 0-5.0 VDC
 Response Time 0.1 sec.
 Accuracy 0.02 µg/l

Source: Anupama, K., et al. “Multi-parameter ocean monitoring system using Underwater Wireless Sensor Networks”
48

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

 Acoustic Modem
 S2CM HS Modem – EvoLogics
 Data Rate - 62.5kbps
 Operating Depth – 200m
 BER- less than 10 -10
 Internal Data Buffer- 1 MB, configurable
 Host I/f - Ethernet or RS-232
 Power Consumption
 Stand-by Mode 0.5 mW
 Receive Mode 0.8 W
 Transmit Mode 3.5 W, 200 m range, 10 W, max.
 Power Supply
 External 24 VDC (12 VDC optional)
Source: https://www.evologics.de/files/DataSheets/EvoLogics_S2CM-HS-Product_Information.pdf
49

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

Sensors Connect
Sensors via ADC
 Current to Voltage Converter Module H8G6 – Converts 4- 20
mA to 0-3.3V
 Connected to ADC
 6 Sensors – 6 Channels of ADC of LPC 2378 AD0- AD5

Source: Anupama, K., et al. “Multi-parameter ocean monitoring system using Underwater Wireless Sensor Networks” 50

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

Sensing Interval
Every 5 Minutes – Use Timer 0 - Match

Acoustic Modem
 Connected via Serial Communication interface
Serial Communication – LPC 23XX
 16 byte Receive and Transmit FIFOs.
 Receiver FIFO trigger points at 1, 4, 8, and 14 bytes.
 Built-in baud rate generator.

Source: Anupama, K., et al. “Multi-parameter ocean monitoring system using Underwater Wireless Sensor Networks” 51

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

Source: http://www.ti.com/lit/ds/slvsc40g/slvsc40g.pdf
52

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

 The system is powered by a battery pack made from 6 Tenergy
1.2 V, 5000, mA hour NiMH cells in a series configuration.
 The battery pack is fused with a 2 A fuse and is recharged at an
optimal rate of 600 mA.
 The system has a dedicated board for GPS, RF
 A u-blox6 GPS receiver is used with a Sarantel Helical GPS antenna
(GeoHelix SL1300) to yield good localization near the water
surface.
 Semtech SX1230 RF transmitter is programmed to send GPS
coordinates from the unit over an RF link at 434 MHz with a usable
range of 500–1,000 m.
Source: Anupama, K., et al. “Multi-parameter ocean monitoring system using Underwater Wireless Sensor Networks”
53

BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956

Thank You .

BITS Pilani, Deemed to be University under Section 3, UGC Act