Embedded Firmware Design and Development – Firmware Design Approaches, Firmware Development Languages. Integration of Embedded Hardware and Firmware. Embedded Product Development Life Cycle – Objectives, Different Phases, Modeling Techniques – Waterfall Model, Incremental Model, Evolutionary Model, Spiral Model.

1. 1 / 118
Embedded Firmware
Design and Development,
and EDLC
Module 4

2. 2 / 118
EMBEDDED FIRMWARE DESIGN APPROACHES
●
The firmware design approaches for embedded product is
purely dependent on the complexity of the functions to be
performed, the speed of operation required, etc.
●
Two basic approaches are used for Embedded firmware design.
●
They are ‘Conventional Procedural Based Firmware Design’ and
‘ Embedded Operating System (OS) Based Design’.
●
The conventional procedural based design is also known as
‘Super Loop Model’.
●
The Super Loop Based Approach
– The Super Loop based firmware development approach is
adopted for applications that are not time critical and where
the response time is not so important.
– It is very similar to a conventional procedural programming
where the code is executed task by task.
– The task listed at the top of the program code is executed
first and the tasks just below the top are executed after
completing the first task.

3. 3 / 118
– This is a true procedural one.
– In a multiple task based system, each task is executed in
serial in this approach.
– The firmware execution flow for this will be
1. Configure the common parameters and perform
initialisation for various hardware components memory,
registers, etc.
2. Start the first task and execute it
3. Execute the second task
4. Execute the next task
5. :
6. :
7. Execute the last defined task
8. Jump back to the first task and follow the same flow
– From the firmware execution sequence, it is obvious that the
order in which the tasks to be executed are fixed and they are
hard coded in the code itself.
– Also the operation is an infinite loop based approach.

4. 4 / 118
– Almost all tasks in embedded applications are non-ending
and are repeated infinitely throughout the operation.
– From the above ‘C’ code you can see that the tasks 1 to n are
performed one after another and when the last task (n th
task) is executed, the firmware execution is again re-directed
to Task 1 and it is repeated forever in the loop.
– This repetition is achieved by using an infinite loop. Here the
while (1) { } loop.
– This approach is also referred as ‘Super loop based
Approach’.
– Since the tasks are running inside an infinite loop, the only
way to come out of the loop is either a hardware reset or an
interrupt assertion.

5. 5 / 118
– A hardware reset brings the program execution back to the
main loop.
– Whereas an interrupt request suspends the task execution
temporarily and performs the corresponding interrupt routine
and on completion of the interrupt routine it restarts the task
execution from the point where it got interrupted.
– The ‘Super loop based design’ doesn’t require an operating
system, since there is no need for scheduling which task is to
be executed and assigning priority to each task.
– In a super loop based design, the priorities are fixed and the
order in which the tasks to be executed are also fixed.
– Hence the code for performing these tasks will be residing in
the code memory without an operating system image.
– This type of design is deployed in low-cost embedded
products and products where response time is not time
critical.
– Some embedded products demands this type of approach if
some tasks itself are sequential.

6. 6 / 118
– For example, reading/writing data to and from a card using a
card reader requires a sequence of operations like checking
the presence of card, authenticating the operation,
reading/writing, etc. it should strictly follow a specified
sequence and the combination of these series of tasks
constitutes a single task-namely data read/ write.
– There is no use in putting the sub-tasks into independent
tasks and running them parallel. It won’t work at all.
– A typical example of a ‘Super loop based’ product is an
electronic video game toy containing keypad and display
unit.
– The program running inside the product may be designed in
such a way that it reads the keys to detect whether the user
has given any input and if any key press is detected the
graphic display is updated.
– The keyboard scanning and display updating happens at a
reasonably high rate.
– Even if the application misses a key press, it won’t create
any critical issues; rather it will be treated as a bug in the
firmware.

7. 7 / 118
– It is not economical to embed an OS into low cost products
and it is an utter waste to do so if the response requirements
are not crucial.
– The ‘Super loop based design’ is simple and straight forward
without any OS related overheads.
– The major drawback of this approach is that any failure in any
part of a single task may affect the total system.
– If the program hangs up at some point while executing a task,
it may remain there forever and ultimately the product stops
functioning.There are remedial measures for overcoming this.
– Use of Hardware and software Watch Dog Timers (WDTs)
helps in coming out from the loop when an unexpected failure
occurs or when the processor hangs up.
– This, in turn, may cause additional hardware cost and
firmware overheads.
– Another major drawback of the ‘Super loop’ design approach
is the lack of real timeliness.
– If the number of tasks to be executed within an application
increases, the time at which each task is repeated also
increases.

8. 8 / 118
– This brings the probability of missing out some events.
– For example in a system with Keypads, according to the
‘Super loop design’, there will be a task for monitoring the
keypad connected I/O lines and this need not be the task
running while you press the keys.
– In order to identify the key press, you may have to press the
keys for a sufficiently long time till the keypad status
monitoring task is executed internally by the firmware.
– This will really lead to the lack of real timeliness. There are
corrective measures for this also.
– The best advised option in use interrupts for external events
requiring real time attention.
– Advances in processor technology brings out low cost high
speed processors/controllers, use of such processors in super
loop design greatly reduces the time required to service
different tasks and thereby are capable of providing a nearly
real time attention to external events.

9. 9 / 118
●
The Embedded Operating System (OS) Based Approach
– The Operating System (OS) based approach contains
operating systems, which can be either a General Purpose
Operating System (GPOS) or a Real Time Operating System
(RTOS) to host the user written application firmware.
– The General Purpose OS (GPOS) based design is very similar
to a conventional PC based application development where
the device contains an operating system (Windows/Unix/
Linux, etc. for Desktop PCs) and you will be creating and
running user applications on top of it.
– Example of a GPOS used in embedded product development
is Microsoft® Windows Embedded 8.1 which offers
customisation to use with a range of industry devices like
Handhelds, Point of Sale Terminals, Patient Monitoring
Systems, etc.
– Use of GPOS in embedded products merges the demarcation
of Embedded Systems and general computing systems in
terms of OS.
– For Developing applications on top of the OS, the OS
supported APIs are used.

10. 10 / 118
– Similar to the different hardware specific drivers, OS based
applications also require ‘Driver software’ for different
hardware present on the board to communicate with them.
– Real Time Operating System (RTOS) based design approach is
employed in embedded products demanding Real-time
response.
– RTOS respond in a timely and predictable manner to events.
– Real Time operating system contains a Real Time kernel
responsible for performing pre-emptive multitasking,
scheduler for scheduling tasks, multiple threads, etc.
– A Real Time Operating System (RTOS) allows flexible
scheduling of system resources like the CPU and memory and
offers some way to communicate between tasks.
– ‘Windows Embedded Compact’, ‘pSOS’, ‘VxWorks’, ‘ThreadX’,
‘MicroC/OS-III’, ‘Embedded Linux’,‘Symbian’ etc are examples
of RTOS employed in embedded product development.

11. 11 / 118
EMBEDDED FIRMWARE DEVELOPMENT LANGUAGES
●
Assembly Language based Development
– Assembly language’ is the human readable notation of ‘
machine language’, whereas ‘machine language’ is a
processor understandable language.
– Processors deal only with binaries (1s and 0s).
– Machine language is a binary representation and it consists
of 1s and 0s.
– Machine language is made readable by using specific
symbols called ‘ mnemonics’.
– Hence machine language can be considered as an interface
between processor and programmer.
– Assembly language and machine languages are processor
/controller dependent and an assembly program written for
one processor/controller family will not work with others.
– Assembly language programming is the task of writing
processor specific machine code in mnemonic form,
converting the mnemonics into actual processor instructions
(machine language) and associated data using an assembler.

12. 12 / 118
– Assembly Language program was the most common type of
programming adopted in the beginning of software
revolution.
– If we look back to the history of programming, we can see
that a large number of programs were written entirely in
assembly language.
– Even today also almost all low level, system related,
programming is carried out using assembly language.
– Some Operating System dependent tasks require low-level
languages.
– In particular, assembly language is often used in writing the
low level interaction between the operating system and the
hardware, for instance in device drivers.
– The general format of an assembly language instruction is an
Opcode followed by Operands.
– The Opcode tells the processor/controller what to do and the
Operands provide the data and information required to
perform the action specifi ed by the opcode.
– It is not necessary that all opcode should have Operands
following them.

13. 13 / 118
MOV A, #30
– This instruction mnemonic moves decimal value 30 to the
8051 Accumulator register.
– Here MOV A is the Opcode and 30 is the operand (single
operand).
– The same instruction when written in machine language will
look like
01110100 00011110
– where the first 8 bit binary value 01110100 represents the
opcode MOV A and the second 8 bit binary value 00011110
represents the operand 30.
– The mnemonic INC A is an example for instruction holding
operand implicitly in the Opcode.
– The machine language representation of the same is
00000100.
– This instruction increments the 8051 Accumulator register
content by 1.

14. 14 / 118
– The mnemonic MOV A, #30 explained above is an example
for single operand instruction.
– LJMP 16bit address is an example for dual operand
instruction.
– The machine language for the same is
00000010 addr_bit15 to addr_bit 8 addr_bit7 to addr_bit 0
– The first binary data is the representation of the LJMP
machine code.
– The first operand that immediately follows the opcode
represents the bits 8 to 15 of the 16bit address to which the
jump is required and the second operand represents the bits
0 to 7 of the address to which the jump is targeted.
– Assembly language instructions are written one per line.
– A machine code program thus consists of a sequence of
assembly language instructions, where each statement
contains a mnemonic ( Opcode + Operand).
– Each line of an assembly language program is split into four
fields as given below
LABEL OPCODE OPERAND COMMENTS

15. 15 / 118
– LABEL is an optional field. A ‘LABEL’ is an identifier used
extensively in programs to reduce the reliance on
programmers for remembering where data or code is
located.
– LABEL is commonly used for representing
●
A memory location, address of a program, sub-routine,
code portion, etc.
●
The maximum length of a label differs between
assemblers. Assemblers insist strict formats for labelling.
Labels are always suffi xed by a colon and begin with a
valid character. Labels can contain number from 0 to 9
and special character _ (underscore).
– Labels are used for representing subroutine names and jump
locations in Assembly language programming.
– It is to be noted that ‘LABEL’ is not a mandatory field; it is
optional only.

16. 16 / 118
– The Assembly program contains a main routine which starts at
address 0000H and it may or may not contain subroutines.
– The example given above is a subroutine, where in the main
program the subroutine is invoked by the Assembly instruction
LCALL DELAY
– Executing this instruction transfers the program flow to the
memory address referenced by the ‘LABEL’ DELAY
.
– It is a good practice to provide comments to your subroutines
before the beginning of it by indicating the purpose of that
subroutine, what the input parameters are and how they are
passed to the subroutines, which are the return values, how
they are returned to the calling function, etc.

17. 17 / 118
– While assembling the code a ‘;’ informs the assembler that the
rest of the part coming in a line after the ‘;’ symbol is
comments and simply ignore it.
– Each Assembly instruction should be written in a separate line.
– Unlike C and other high level languages, more than one ASM
code lines are not allowed in a single line.
– In the above example the LABEL DELAY represents the
reference to the start of the subroutine DELAY
.
– You can directly replace this LABEL by putting the desired
address first and then writing the Assembly code for the
routine as given below.
– The advantage of using a label is that the required address is
calculated by the assembler at the time of assembling the
program and it replaces the Label.

18. 18 / 118
– Hence even if you add some code above the LABEL ‘DELAY’
at a later stage, it won’t create any issues like code
overlapping, whereas in the second method where you are
implicitly telling the assembler that this subroutine should
start at the specified address (in the above example 0100H).
– If the code written above this subroutine itself is crossing the
0100H mark of the program memory, it will be over written
by the subroutine code and it will generate unexpected
results.
– Hence for safety don’t assign any address by yourself, let us
refer the required address by using labels and let the
assembler handle the responsibility for finding out the
address where the code can be placed.
– In the above example you can find out that the label DELAY
is used for calling the subroutine as well as looping (using
jumping instruction based on decision-DJNZ).
– You can also use the normal jump instruction to jump to the
label by calling LJMP DELAY
.
– The statement ORG 0100H in the above example is not an
assembly language instruction; it is an assembler directive
instruction.

19. 19 / 118
– It tells the assembler that the Instructions from here onward
should be placed at location starting from 0100H.
– The Assembler directive instructions are known as ‘pseudo-
ops’. They are used for
1. Determining the start address of the program (e.g. ORG
0000H)
2. Determining the entry address of the program (e.g.
ORG 0100H)
3. Reserving memory for data variables, arrays and
structures (e.g. var EQU 70H
4. Initialising variable values (e.g. val DATA 12H)
– The EQU directive is used for allocating memory to a variable
and DATA directive is used for initialising a variable with
data.
– No machine codes are generated for the ‘pseudo-ops’.
– The Assembly language program written in assembly code is
saved as .asm (Assembly file) file or an .src (source) file or an
extension format supported by the tool chain/assembler.

20. 20 / 118
– Similar to ‘C’ and other high level language programming,
you can have multiple source files called modules in
assembly language programming.
– Each module is represented by an ‘.asm’ or ‘.src’ or a file with
an extension format specific to the ttol chain/assembler used
similar to the ‘.c’ files in C programming.
– This approach is known as ‘Modular Programming’.
– Modular programming is employed when the program is too
complex or too big.
– In ‘Modular Programming’, the entire code is divided into
submodules and each module is made re-usable.
– Modular Programs are usually easy to code, debug and alter.
– Source File to Object File Translation
●
Translation of assembly code to machine code is
performed by assembler.
●
The assemblers for different target machines are different
and it is common that assemblers from multiple vendors
are available in the market for the same target machines.

21. 21 / 118
●
Some target processor’s/controller’s assembler may be
proprietary and is supplied by a single vendor only.
●
Some assemblers are freely available in the internet for
downloading.
●
Some assemblers are commercial and requires licence
from the vendor.

22. 22 / 118
●
Each source module is written in Assembly and is stored
as .src file or .asm file.
●
Each file can be assembled separately to examine the
syntax errors and incorrect assembly instructions.
●
On successful assembling of each .src/.asm file a
corresponding object file is created with extension ‘.obj’.
●
The object file does not contain the absolute address of
where the generated code needs to be placed on the
program memory and hence it is called a re-locatable
segment.
●
It can be placed at any code memory location and it is
the responsibility of the linker/locator to assign absolute
address for this module.
●
Absolute address allocation is done at the absolute object
file creation stage.
●
Each module can share variables and subroutines
(functions) among them.
●
Exporting a variable/function from a module (making a
variable/function from a module available to all other
modules) is done by declaring that variable/function as
PUBLIC in the source module.

23. 23 / 118
●
Importing a variable or function from a module (taking a
variable or function from any one of other modules) is
done by declaring that variable or function as EXTRN
(EXTERN) in the module where it is going to be accessed.
●
The ‘PUBLIC’ Keyword informs the assembler that the
variables or functions declared as ‘PUBLIC’ needs to be
exported.
●
Similarly the ‘EXTRN’ Keyword tells the assembler that the
variables or functions declared as ‘EXTRN’ needs to be
imported from some other modules.
●
While assembling a module, on seeing variables/functions
with keyword ‘EXTRN’, the assembler understands that
these variables or functions come from an external
module and it proceeds assembling the entire module
without throwing any errors, though the assembler cannot
find the definition of the variables and implementation of
the functions.
●
Corresponding to a variable or function declared as
‘PUBLIC’ in a module, there can be one or more modules
using these variables or functions using ‘EXTRN’ keyword.

24. 24 / 118
●
For all those modules using variables or functions with
‘EXTRN’ keyword, there should be one and only one
module which exports those variables or functions with
‘PUBLIC’ keyword.
●
If more than one module in a project tries to export
variables or functions with the same name using ‘PUBLIC’
keyword, it will generate ‘linker’ errors.
●
If a variable or function declared as ‘EXTRN’ in one or two
modules, there should be one module defining these
variables or functions and exporting them using ‘PUBLIC’
keyword.
●
If no modules in a project export the variables or functions
which are declared as ‘EXTRN’ in other modules, it will
generate ‘linker’ warnings or errors depending on the
error level/warning level settings of the linker.
– Library File Creation and Usage
●
Libraries are specially formatted, ordered program
collections of object modules that may be used by the
linker at a later time.

25. 25 / 118
●
When the linker processes a library, only those object
modules in the library that are necessary to create the
program are used.
●
Library files are generated with extension ‘.lib’.
●
Library file is some kind of source code hiding technique.
●
If you don’t want to reveal the source code behind the
various functions you have written in your program and at
the same time you want them to be distributed to
application developers for making use of them in their
applications, you can supply them as library files and give
them the details of the public functions available from the
library (function name, function input/output, etc).
●
For using a library file in a project, add the library to the
project.
●
If you are using a commercial version of the assembler
/compiler suite for your development, the vendor of the
utility may provide you pre-written library files for
performing multiplication, floating point arithmetic, etc. as
an add-on utility or as a bonus.
●
‘LIB51’ from Keil Software is an example for a library
creator and it is used for creating library files for A51
Assembler/C51 Compiler for 8051 specific controller.

26. 26 / 118
– Linker and Locator
●
Linker and Locator is another software utility responsible
for “linking the various object modules in a multi-module
project and assigning absolute address to each module”.
●
Linker generates an absolute object module by extracting
the object modules from the library, if any and those obj
files created by the assembler, which is generated by
assembling the individual modules of a project.
●
It is the responsibility of the linker to link any external
dependent variables or functions declared on various
modules and resolve the external dependencies among
the modules.
●
An absolute object file or module does not contain any re-
locatable code or data.
●
All code and data reside at fixed memory locations.
●
The absolute object file is used for creating hex files for
dumping into the code memory of the processor
/controller.
●
‘BL51’ from Keil Software is an example for a Linker &
Locator for A51 Assembler/C51 Compiler for 8051 specific
controller.

27. 27 / 118
– Object to Hex File Converter
●
This is the final stage in the conversion of Assembly
language (mnemonics) to machine understandable
language (machine code).
●
Hex File is the representation of the machine code and the
hex file is dumped into the code memory of the
processor/controller.
●
The hex file representation varies depending on the target
processor/controller make.
●
For Intel processors/controllers the target hex file format
will be ‘Intel HEX’ and for Motorola, the hex file should be
in ‘Motorola HEX’ format.
●
HEX files are ASCII files that contain a hexadecimal
representation of target application.
●
Hex file is created from the final ‘Absolute Object File’
using the Object to Hex File Converter utility.
●
‘OH51’ from Keil software is an example for Object to Hex
File Converter utility for A51 Assembler/C51 Compiler for
8051 specific controller.

28. 28 / 118
– Advantages of Assembly Language Based Development
●
Assembly Language based development was the most
common technique adopted from the beginning of
embedded technology development.
●
Thorough understanding of the processor architecture,
memory organisation, register sets and mnemonics is very
essential for Assembly Language based development.
●
If you master one processor architecture and its assembly
instructions, you can make the processor as flexible as a
gymnast.
●
The major advantages of Assembly Language based
development is listed below.
– Efficient Code Memory and Data Memory Usage
(Memory Optimisation)
●
Since the developer is well versed with the target
processor architecture and memory organisation,
optimised code can be written for performing
operations.
●
This leads to less utilisation of code memory and
efficient utilisation of data memory.

29. 29 / 118
●
Remember memory is a primary concern in any
embedded product (Though silicon is cheaper and
new memory techniques make memory less costly,
external memory operations impact directly on
system performance).
– High Performance
●
Optimised code not only improves the code
memory usage but also improves the total system
performance.
●
Through effective assembly coding, optimum
performance can be achieved for a target
application.
– Low Level Hardware Access
●
Most of the code for low level programming like
accessing external device specific registers from
the operating system kernel, device drivers, and
low level interrupt routines, etc. are making use of
direct assembly coding since low level device
specific operation support is not commonly
available with most of the high-level language cross
compilers.

30. 30 / 118
– Code Reverse Engineering
●
Reverse engineering is the process of understanding
the technology behind a product by extracting the
information from a finished product.
●
Reverse engineering is performed by ‘hackers’ to
reveal the technology behind ‘Proprietary Products’.
●
Though most of the products employ code memory
●
protection, if it may be possible to break the
memory protection and read the code memory, it
can easily be converted into assembly code using a
dis-assembler program for the target machine.
– Drawbacks of Assembly Language Based Development
●
Every technology has its own pros and cons.
●
From certain technology aspects assembly language
development is the most efficient technique.
●
But it is having the following technical limitations also.
– High Development Time
●
Assembly language is much harder to program than
high level languages.

31. 31 / 118
●
The developer must pay attention to more details
and must have thorough knowledge of the
architecture, memory organisation and register
details of the target processor in use.
●
Learning the inner details of the processor and its
assembly instructions is highly time consuming and
it creates a delay impact in product development.
●
One probable solution for this is use a readily
available developer who is well versed in the target
processor architecture assembly instructions.
●
Also more lines of assembly code are required for
performing an action which can be done with a
single instruction in a high-level language like ‘C’.
– Developer Dependency
●
There is no common written rule for developing
assembly language based applications whereas all
high level languages instruct certain set of rules for
application development.
●
In assembly language programming, the developers
will have the freedom to choose the different
memory location and registers.

32. 32 / 118
●
Also the programming approach varies from
developer to developer depending on his/her taste.
●
For example moving data from a memory location
to accumulator can be achieved through different
approaches.
●
If the approach done by a developer is not
documented properly at the development stage,
he/ she may not be able to recollect why this
approach is followed at a later stage or when a
new developer is instructed to analyse this code,
he/she also may not be able to understand what is
done and why it is done.
●
Hence upgrading an assembly program or
modifying it on a later stage is very difficult.
●
Well documenting the assembly code is a solution
for reducing the developer dependency in
assembly language programming.
●
If the code is too large and complex, documenting
all lines of code may not be productive.

33. 33 / 118
– Non-Portable
●
Target applications written in assembly instructions
are valid only for that particular family of processors
(e.g. Application written for Intel x86 family of
processors) and cannot be re-used for another
target processors/controllers (Say ARM Cortex M
family of processors).
●
If the target processor/controller changes, a
complete re-writing of the application using the
assembly instructions for the new target
processor/controller is required.
●
This is the major drawback of assembly language
programming and it makes the assembly language
applications non-portable.
– Though Assembly Language programming possesses lots of
drawback, as a developer, from my personal experience I
prefer assembly language based development.
– Once you master the internals of a processor/controller, you
can really perform magic with the processor/controller and
can extract the maximum out of it.

34. 34 / 118
●
High Level Language Based Development
– Assembly language based programming is highly time
consuming, tedious and requires skilled programmers with
sound knowledge of the target processor architecture.
– Applications developed in Assembly language are non-
portable.Here comes the role of high level languages.
– Any high level language with a supported cross compiler
(for converting the application developed in high level
language to target processor specific assembly code) for
the target processor can be used for embedded firmware
development.
– The most commonly used high level language for
embedded firmware application development is ‘C’.
– “C is the well defined, easy to use high level language with
extensive cross platform development tool support”.
– Nowadays Cross-compilers for C++ is also emerging out
and embedded developers are making use of C++ for
embedded application development.

35. 35 / 118
– The various steps involved in high level language based
embedded firmware development is same as that of
assembly language based development except that the
conversion of source file written in high level language to
object file is done by a cross-compiler, whereas in Assembly
language based development it is carried out by an
assembler.

36. 36 / 118
– The program written in any of the high level language is
saved with the corresponding language extension.
– Most of the high level languages support modular
programming approach and hence you can have multiple
source files called modules written in corresponding high
level language.
– The source files corresponding to each module is represented
by a file with corresponding language extension.
– Translation of high level source code to executable object
code is done by a cross-compiler.
– The cross-compilers for different high level languages for the
same target processor are different.
– It should be noted that each high level language should have
a cross-compiler for converting the high level source code
into the target processor machine code.
– Without cross-compiler support a high level language cannot
be used for embedded firmware development.
– Conversion of each module’s source code to corresponding
object file is performed by the cross compiler.

37. 37 / 118
– Rest of the steps involved in the conversion of high level
language to target processor’s machine code are same as
that of the steps involved in assembly language based
development.
●
Advantages of High Level Language Based Development
– Reduced Development
●
Time Developer requires less or little knowledge on
the internal hardware details and architecture of
the target processor/controller.
●
Bare minimal knowledge of the memory
organisation and register details of the target
processor in use and syntax of the high level
language are the only pre-requisites for high level
language based firmware development.
●
Rest of the things will be taken care of by the cross-
compiler used for the high level language.
●
Thus the ramp up time required by the developer in
understanding the target hardware and target
machine’s assembly instructions is waived off by
the cross compiler and it reduces the development
time by significant reduction in developer effort.

38. 38 / 118
●
High level language based development also refines
the scope of embedded firmware development from
a team of specialised architects to anyone knowing
the syntax of the language and willing to put little
effort on understanding the minimal hardware
details.
●
With high level language, each task can be
accomplished by lesser number of lines of code
compared to the target processor/controller specific
Assembly language based development.
– Developer Independency
●
The syntax used by most of the high level languages
are universal and a program written in the high level
language can easily be understood by a second
person knowing the syntax of the language.
●
Certain instructions may require little knowledge of
the target hardware details like register set, memory
map etc.
●
Apart from these, the high level language based
firmware development makes the firmware,
developer independent.

39. 39 / 118
●
High level languages always instruct certain set of
rules for writing the code and commenting the
piece of code.
●
If the developer strictly adheres to the rules, the
firmware will be 100% developer independent.
– Portability
●
Target applications written in high level languages
are converted to target processor/controller
understandable format (machine codes) by a
cross-compiler.
●
An application written in high level language for a
particular target processor can easily be converted
to another target processor/controller specific
application, with little or less effort by simply re-
compiling/little code modification followed by re-
compiling the application for the required target
processor/controller, provided, the cross-compiler
has support for the processor/controller selected.
●
This makes applications written in high level
language highly portable.

40. 40 / 118
●
Little effort may be required in the existing code to
replace the target processor specific header files
with new header files, register definitions with new
ones, etc.
●
This is the major flexibility offered by high level
language based design.
●
Limitations of High Level Language Based Development
– The merits offered by high level language based
design take advantage over its limitations.
– Some cross-compilers available for high level
languages may not be so efficient in generating
optimised target processor specific instructions.
– Target images created by such compilers may be
messy and non-optimised in terms of performance as
well as code size.
– For example, the task achieved by cross-compiler
generated machine instructions from a high level
language may be achieved through a lesser number of
instructions if the same task is hand coded using
target processor specific machine codes.

41. 41 / 118
– The time required to execute a task also increases with
the number of instructions.
– However modern cross-compilers are tending to adopt
designs incorporating optimisation techniques for both
code size and performance.
– High level language based code snippets may not be
efficient in accessing low level hardware where
hardware access timing is critical.
– The investment required for high level language based
development tools is high compared to Assembly
Language based firmware development tools.
●
Mixing Assembly and High Level Language
– Certain embedded firmware development situations may
demand the mixing of high level language with Assembly
and vice versa.
– High level language and assembly languages are usually
mixed in three ways; namely,
●
mixing Assembly Language with High Level Language,
●
mixing High Level Language with Assembly
●
In-line Assembly programming.

42. 42 / 118
– Mixing Assembly with High level language (e.g. Assembly
Language with ‘C’)
●
Assembly routines are mixed with ‘C’ in situations where
the entire program is written in ‘C’ and the cross compiler
in use do not have a built in support for implementing
certain features like Interrupt Service Routine functions
(ISR) or if the programmer wants to take advantage of
the speed and optimised code offered by machine code
generated by hand written assembly rather than cross
compiler generated machine code.
●
When accessing certain low level hardware, the timing
specifications may be very critical and a cross compiler
generated binary may not be able to offer the required
time specifications accurately.
●
Writing the hardware/peripheral access routine in
processor/controller specific Assembly language and
invoking it from ‘C’ is the most advised method to handle
such situations.

43. 43 / 118
●
Mixing ‘C’ and Assembly is little complicated in the sense
—the programmer must be aware of how parameters are
passed from the ‘C’ routine to Assembly and values are
returned from assembly routine to ‘C’and how ‘Assembly
routine’ is invoked from the ‘C’ code.
●
Passing parameter to the assembly routine and returning
values from the assembly routine to the caller ‘C’ function
and the method of invoking the assembly routine from ‘C’
code is cross compiler dependent.
●
There is no universal written rule for this. You must get
these informations from the documentation of the cross
compiler you are using.
●
Different cross compilers implement these features in
different ways depending on the general purpose
registers and the memory supported by the target
processor/controller.
●
The special compiler directive SRC generates the
Assembly code corresponding to the ‘C’ function and each
lines of the source code is converted to the corresponding
Assembly instruction.

44. 44 / 118
●
You can easily identify the Assembly code generated for
each line of the source code since it is implicitly
mentioned in the generated .SRC file.
●
By inspecting this code segments you can find out which
registers are used for holding the variables of the ‘C’
function and you can modify the source code by adding
the assembly routine you want.
●
Mixing High Level Language with Assembly (e.g. ‘C’ with
Assembly Language)
– Mixing the code written in a high level language like ‘C’ and
Assembly language is useful in the following scenarios:
1. The source code is already available in Assembly
language and a routine written in a high level language
like ‘C’ needs to be included to the existing code.
2. The entire source code is planned in Assembly code for
various reasons like optimised code, optimal performance,
efficient code memory utilisation and proven expertise in
handling the Assembly, etc. But some portions of the code
may be very difficult and tedious to code in Assembly. For
example 16bit multiplication and division in 8051
Assembly Language.

45. 45 / 118
3. To include built in library functions written in ‘C’
language provided by the cross compiler. For example
Built in Graphics library functions and String operations
supported by ‘C’.
– Most often the functions written in ‘C’ use parameter passing
to the function and returns value/s to the calling functions.
– The major question that needs to be addressed in mixing a
‘C’ function with Assembly is that how the parameters are
passed to the function and how values are returned from the
function and how the function is invoked from the assembly
language environment.
– Parameters are passed to the function and values are
returned from the function using CPU registers, stack
memory and fixed memory.
– Its implementation is cross compiler dependent and it varies
across cross compilers.
●
Inline Assembly
– Inline assembly is another technique for inserting target
processor/controller specific Assembly instructions at any
location of a source code written in high level language ‘C’.

46. 46 / 118
– This avoids the delay in calling an assembly routine from a
‘C’ code (If the Assembly instructions to be inserted are put
in a subroutine as mentioned in the section mixing assembly
with ‘C’).
– Special keywords are used to indicate that the start and end
of Assembly instructions.
– The keywords are cross-compiler specific.

47. 47 / 118
INTEGRATION OF HARDWARE AND FIRMWARE
●
Integration of hardware and firmware deals with the embedding
of firmware into the target hardware board.
●
It is the process of ‘Embedding Intelligence’ to the product.
●
The embedded processors/controllers used in the target board
may or may not have built in code memory.
●
For non-operating system based embedded products, if the
processor/controller contains internal memory and the total size
of the firmware is fitting into the code memory area, the code
memory is downloaded into the target controller/processor.
●
If the processor/controller does not support built in code
memory or the size of the firmware is exceeding the memory
size supported by the target processor/controller, an external
dedicated EPROM/FLASH memory chip is used for holding the
firmware.
●
This chip is interfaced to the processor/ controller. (The type of
firmware storage, either processor storage or external storage
is decided at the time of hardware design by taking the
firmware complexity into consideration).
●
A variety of techniques are used for embedding the firmware
into the target board.

48. 48 / 118
●
The commonly used firmware embedding techniques for a non-
OS based embedded system are explained below.
●
The non-OS based embedded systems store the firmware either
in the onchip processor/controller memory or offchip memory
(FLASH/NVRAM, etc.).
– Out-of-Circuit Programming
●
Out-of-circuit programming is performed outside the
target board.
●
The processor or memory chip into which the firmware
needs to be embedded is taken out of the target board
and it is programmed with the help of a programming
device.
●
The programming device is a dedicated unit which
contains the necessary hardware circuit to generate the
programming signals.
●
Most of the programmer devices available in the market
are capable of programming different family of devices
with different pin outs (Pin counts).
●
The programmer contains a ZIF socket with locking pin to
hold the device to be programmed.

49. 49 / 118
●
The programming device will be under the control of a
utility program running on a PC.
●
Usually the programmer is interfaced to the PC through RS-
232C/USB/Parallel Port Interface.
●
The commands to control the programmer are sent from the
utility program to the programmer through the interface.
●
The sequence of operations for embedding the firmware
with a programmer is listed below.
1. Connect the programming device to the specified port
of PC (USB/COM port/parallel port)
2. Power up the device (Most of the programmers
incorporate LED to indicate Device power up. Ensure that
the power indication LED is ON)
3. Execute the programming utility on the PC and ensure
proper connectivity is established between PC and
programmer. In case of error, turn off device power and
try connecting it again
4. Unlock the ZIF socket by turning the lock pin
5. Insert the device to be programmed into the open
socket as per the insert diagram shown on the
programmer.

50. 50 / 118
6. Lock the ZIF socket
7. Select the device name from the list of supported
devices
8. Load the hex file which is to be embedded into the
device
9. Program the device by ‘Program’ option of utility
program
10. Wait till the completion of programming operation
(Till busy LED of programmer is off)
11. Ensure that programming is successful by checking
the status LED on the programmer (Usually ‘Green’ for
success and ‘Red’ for error condition) or by noticing
the feedback from the utility program
12. Unlock the ZIF socket and take the device out of
programmer
●
Now the firmware is successfully embedded into the
device.
●
Insert the device into the board, power up the board and
test it for the required functionalities.

51. 51 / 118
●
It is to be noted that the most of programmers support
only Dual Inline Package (DIP) chips, since its ZIF socket
is designed to accommodate only DIP chips.
●
Hence programming of chips with other packages is not
possible with the current setup.
●
Adaptor sockets which convert a non-DIP package to DIP
socket can be used for programming such chips.
●
One side of the Adaptor socket contains a DIP interface
and the other side acts as a holder for holding the chip
with a non-DIP package (say VQFP).
●
Option for setting firmware protection will be available on
the programming utility.
●
If you really want the firmware to be protected against
unwanted external access, and if the device is supporting
memory protection, enable the memory protection on the
utility before programming the device.
●
The programmer usually erases the existing content of
the chip before programming the chip.
●
Only EEPROM and FLASH memory chips are erasable by
the programmer.

52. 52 / 118
●
Some old embedded systems may be built around
UVEPROM chips and such chips should be erased using a
separate ‘UV Chip Eraser’ before programming.
●
The major drawback of out-of-circuit programming is the
high development time.
●
Whenever the firmware is changed, the chip should be
taken out of the development board for re-programming.
●
This is tedious and prone to chip damages due to frequent
insertion and removal.
●
Better use a socket on the board side to hold the chip till
the firmware modifications are over.
●
The programmer facilitates programming of only one chip
at a time and it is not suitable for batch production.
●
Using a ‘Gang Programmer’ resolves this limitation to
certain extent.
●
A gang programmer is similar to an ordinary programmer
except that it contains multiple ZIF sockets (say 4 to 8)
and capable of programming multiple devices at a time.
●
But it is bit expensive compared to an ordinary
programmer.

53. 53 / 118
●
Another big drawback of this programming technique is
that once the product is deployed in the market in a
production environment, it is very difficult to upgrade the
firmware.
●
The out-of-system programming technique is used for
firmware integration for low end embedded products
which runs without an operating system.
●
Out-of-circuit programming is commonly used for
development of low volume products and Proof of Concept
(PoC) product Development.
– In System Programming (ISP)
●
With ISP, programming is done ‘within the system’,
meaning the firmware is embedded into the target device
without removing it from the target board.
●
It is the most flexible and easy way of firmware
embedding.
●
The only pre-requisite is that the target device must have
an ISP support.
●
Apart from the target board, PC, ISP cable and ISP utility,
no other additional hardware is required for ISP.

54. 54 / 118
●
Chips supporting ISP generates the necessary
programming signals internally, using the chip’s supply
voltage.
●
The target board can be interfaced to the utility program
running on PC through Serial Port/Parallel Port/USB.
●
The communication between the target device and ISP
utility will be in a serial format.
●
The serial protocols used for ISP may be ‘Joint Test Action
Group ( JTAG)’ or ‘ Serial Peripheral Interface (SPI)’ or any
other proprietary protocol.
●
In order to perform ISP operations the target device (in
most cases the target device is a microcontroller
/microprocessor) should be powered up in a special ‘ISP
mode’.
●
ISP mode allows the device to communicate with an
external host through a serial interface, such as a PC or
terminal.
●
The device receives commands and data from the host,
erases and reprograms code memory according to the
received command.

55. 55 / 118
●
Once the ISP operations are completed, the device is re-
configured so that it will operate normally by applying a
reset or a re-power up
– In System Programming with SPI Protocol
●
Devices with SPI In System Programming support
contains a built-in SPI interface and the on-chip
EEPROM or FLASH memory is programmed through
this interface.
●
The primary I/O lines involved in SPI – In System
Programming are listed below.
●
MOSI – Master Out Slave In
●
MISO – Master In Slave Out
●
SCK – System Clock
●
RST – Reset of Target Device
●
GND – Ground of Target Device
●
PC acts as the master and target device acts as the
slave in ISP.
●
The program data is sent to the MOSI pin of target
device and the device acknowledgement is
originated from the MISO pin of the device.
●
SCK pin acts as the clock for data transfer.

56. 56 / 118
●
A utility program can be developed on the PC side to
generate the above signal lines.
●
Since the target device works under a supply
voltage less than 5V (TTL/CMOS), it is better to
connect these lines of the target device with the
parallel port of the PC.
●
Since Parallel port operations are also at 5V logic, no
need for any other intermediate hardware for signal
conversion.
●
The pins of parallel port to which the ISP pins of
device needs to be connected are dependent on the
program, which is used for generating these signals,
or you can fix these lines first and then write the
program according to the pin inter-connection
assignments.
●
Standard SPI-ISP utilities are feely available on the
internet and there is no need for going for writing
own program.
●
What you need to do is just connect the pins as
mentioned by the program requirement.
●
In ISP operations, the target device needs to be
powered up in a pre-defined sequence.

57. 57 / 118
●
The key player behind ISP is a factory programmed
memory (ROM) called ‘Boot ROM’.
●
The Boot ROM normally resides at the top end of
code memory space and it varies in the order of a
few Kilo Bytes.
●
It contains a set of Low-level Instruction APIs and
these APIs allow the processor/controller to
perform the FLASH memory programming, erasing
and Reading operations.
●
The contents of the Boot ROM are provided by the
chip manufacturer and the same is masked into
every device.
●
The Boot ROM for different family or series devices
is different.
●
By default the Reset vector starts the code
memory execution at location 0000H.
●
If the ISP mode is enabled through the special ISP
Power up sequence, the execution will start at the
Boot ROM vector location.

58. 58 / 118
●
ISP technique is the most recommended
programming technique for development work
since the effort required to re-program the device in
case of firmware modification is very little.
●
Firmware upgrades for products supporting ISP is
quite simple.
– In Application Programming ( IAP)
●
In Application Programming (IAP) is a technique used by
the firmware running on the target device for modifying a
selected portion of the code memory.
●
It is not a technique for first time embedding of user
written firmware.
●
It modifies the program code memory under the control
of the embedded application.
●
Updating calibration data, look-up tables, etc., which are
stored in code memory, are typical examples of IAP.
●
The Boot ROM resident API instructions which perform
various functions such as programming, erasing, and
reading the Flash memory during ISP mode, are made
available to the end-user written firmware for IAP.

59. 59 / 118
●
Thus it is possible for an end-user application to perform
operations on the Flash memory.
●
A common entry point to these API routines is provided
for interfacing them to the end-user’s application.
●
Functions are performed by setting up specific registers
as required by a specific operation and performing a call
to the common entry point.
●
Like any other subroutine call, after completion of the
function, control will return to the end-user’s code.
●
The Boot ROM is shadowed with the user code memory in
its address range.
●
This shadowing is controlled by a status bit.
●
When this status bit is set, accesses to the internal code
memory in this address range will be from the Boot ROM.
●
When cleared, accesses will be from the user’s code
memory.
●
Hence the user should set the status bit prior to calling
the common entry point for IAP operations.

60. 60 / 118
– Use of Factory Programmed Chip
●
It is possible to embed the firmware into the target
processor/controller memory at the time of chip
fabrication itself.
●
Such chips are known as ‘ Factory programmed chips’.
Once the firmware design is over and the firmware
achieved operational stability, the firmware files can be
sent to the chip fabricator to embed it into the code
memory.
●
Factory programmed chips are convenient for mass
production applications and it greatly reduces the product
development time.
●
It is not recommended to use factory programmed chips
for development purpose where the firmware undergoes
frequent changes.
●
Factory programmed ICs are bit expensive.
– Firmware Loading for Operating System Based Devices
●
The OS based embedded systems are programmed using
the In System Programming (ISP) technique.

61. 61 / 118
●
OS based embedded systems contain a special piece of
code called ‘Boot loader’ program which takes control of
the OS and application firmware embedding and copying
of the OS image to the RAM of the system for execution.
●
The ‘ Boot loader’ for such embedded systems comes as
pre-loaded or it can be loaded to the memory using the
various interface supported like JTAG.
●
The bootloader contains necessary driver initialisation
implementation for initialising the supported interfaces
like UART/I2C, TCP/IP etc.
●
Bootloader implements menu options for selecting the
source for OS image to load (Typical menu item examples
are Load from FLASH ROM, Load from Network, Load
through UART etc).
●
In case of the network based loading, the bootloader
broadcasts the target’s presence over the network and
the host machine on which the OS image resides can
identify the target device by capturing this message.
●
Once a communication link is established between the
host and target machine, the OS image can be directly
downloaded to the FLASH memory of the target device.

62. 62 / 118
The Embedded Product Development Life Cycle
(EDLC)
●
What EDLC
– Embedded Product Development Life Cycle is an ‘Analysis-
Design-Implementation’ based standard problem solving
approach for Embedded Product Development.
– In any product development application, the first and
foremost step is to figure out what product needs to be
developed (analysis), next you need to figure out a good
approach for building it (design) and last but not least you
need to develop it (implementation).
●
Why EDLC
– EDLC is essential for understanding the scope and
complexity of the work involved in any embedded product
development.
– EDLC defines the interaction and activities among various
groups of a product development sector including project
management, system design and development (hardware,
firmware and enclosure design and development), system
testing, release management and quality assurance.

63. 63 / 118
– The standards imposed by EDLC on a product development
makes the product, developer independent in terms of
standard documents and it also provides uniformity in
development approaches.
●
Objectives of EDLC
– The ultimate aim of any embedded product in a commercial
production setup is to produce marginal benefit.
– Marginal benefit is usually expressed in terms of Return on
Investment (ROI).
– The investment for a product development includes initial
investment, manpower investment, infrastructure
investment, supply chain and marketing expenses, etc.
– A product is said to be profitable only if the turnover from the
selling of the product is more than that of the overall
investment expenditure.
– For this, the product should be acceptable by the end user
and it should meet the requirements of end user in terms of
quality, reliability and functionality.
– So it is very essential to ensure that the product is meeting
all these criteria, throughout the design, development,
implementation and support phases.

64. 64 / 118
– Embedded Product Development Life Cycle (EDLC) helps out
in ensuring all these requirements.
– EDLC has three primary objectives, namely
●
1. Ensure that high quality products are delivered to end
user.
●
2. Risk minimisation and defect prevention in product
development through project management.
●
3. Maximise the productivity.
– Ensuring High Quality for Products
●
The primary definition of quality in any embedded product
development is the Return on Investment (ROI) achieved
by the product.
●
The expenses incurred for developing the product may fall
in any of the categories; initial investment, developer
recruiting, training, or any other infrastructure
requirement related.
●
There will be some budgetary and cost allocation given to
the development of the product and it will be allocated by
some higher officials based on the assumption that the
product will produce a good return or a return justifying
the investment.

65. 65 / 118
●
The budget allocation might have done after studying the
market trends and requirements of the product,
competition, etc.
●
EDLC must ensure that the development of the product has
taken account of all the qualitative attributes of the
embedded system.
– Risk Minimisation and Defect Prevention through Management
●
There are projects in embedded product development
which requires ‘loose’ or ‘tight’ project management.
●
If the product development project is a simple one, a senior
developer itself can take charge of the management
activity and no need for a skilled project manager to look
after this with dedicated effort throughout the development
process, but there should be an overall supervision from a
skilled project management team for ensuring that the
development process is going in the right direction.
●
Projects which are complex and requires timeliness should
have a dedicated and skilled project management part and
hence they are said to be “tightly” bounded to project
management.
●
‘ Project management is essential for predictability, co-
ordination and risk minimisation’.

66. 66 / 118
●
Whenever a product development request comes, an
estimate on the duration of the development and
deployment activity should be given to the end user
/client.
●
The timeframe may be expressed in number of person
days PDS (The effort in terms of single person working for
this much days) or ‘X person for X week (e.g. 2 person 2
week) etc.
●
This is one aspect of predictability.
●
The management team might have reached on this
estimate based on past experience in handling similar
project or on the analysis of work summary or data
available for a similar project, which was logged in using
an activity tool.
●
Resource (Developer) allocation is another aspect of
predictability in management.
●
Resource allocations like how many resources should
work for this project for how many days, how many
resources are critical with respect to the work handling by
them and how many backups required for the resources
to overcome a critical situation where a resource is not
available (Risk minimisation).

67. 67 / 118
●
Resource allocation is critical and it has a direct impact
on investment.
●
The communication aspect of the project management
deals with co-ordination and interaction among partners,
suppliers and client from which the request for the
product development aroused.
●
Project management adds an extra cost on the budget
but it is essential for ensuring the development process is
going in the right direction and the schedules of the
development activity are meeting.
●
Without management, the development work may go
beyond the stipulated time frame (schedule slipping) and
may end up in a product which is not meeting the
requirements from the client side, as a result re-works
should be done to rectify the possible deviations occurred
and it will again put extra cost on the development.
●
Project management makes the proverb “A stitch in time
saves nine” meaningful in an embedded product
development.
●
Apart from resource allocation, project management also
covers activities like task allocation, scheduling,
monitoring and project tracking.

68. 68 / 118
●
Computer Assisted Software Engineering (CASE) Tools and
Gantt charts help the manager in achieving this.
– Increased Productivity
●
Productivity is a measure of efficiency as well as Return on
Investment (ROI).
●
One aspect of productivity covers how many resources are
utilised to build the product, how much investment
required, how much time is taken for developing the
product, etc.
●
For example, the productivity of a system is said to be
doubled if a product developed by a team of ‘X’ members
in a period of ‘X’ days is developed by another team of
‘X/2’ members in a period of ‘X’ days or by a team of ‘X’
members in a period of ‘X/2’ days.
●
This productivity measurement is based on total
manpower efficiency.
●
Productivity in terms of Returns is said to be increased, if
the product is capable of yielding maximum returns with
reduced investment.
●
Saving manpower effort will definitely result in increased
productivity.

69. 69 / 118
●
Usage of automated tools, wherever possible, is
recommended for this.
●
The initial investment on tools may be an additional
burden in terms of money, but it will definitely save efforts
in the next project also.
●
It is a one-time investment. “Pay once use many time”.
●
Another important factor which can help in increased
productivity is “re-usable effort”.
●
Some of the works required for the current product
development may have some common features which you
built for some of the other product development in the
projects you executed before.
●
Identify those efforts and design the new product in such a
way that it can directly be plugged into the new product
without any additional effort.
●
This will definitely increase the productivity by reducing
the development effort.
●
Another advised method for increasing the productivity is
by using resources with specific skill sets which matches
the exact requirement of the entire or part of the product.

70. 70 / 118
●
This reduces the learning time taken by a resource, who
does not have prior expertise in the particular feature or
domain.
●
This is not possible in all product development
environments, since some of the resources with the
desired skill sets may be engaged with some other work
and releasing them from the current work is not possible.
●
Recruiting people with desired skill sets for the current
product development is another option; this is worth only
if you expect to have more work on the near future on the
same technology or skill sets.
●
Use of Commercial Off-the-Shelf Components ( COTS)
wherever possible in a product is a very good way of
reducing the development effort and thereby increasing
the productivity.
●
COTS component is a ready to use component and you
can use the same as plug-in modules in your product.

71. 71 / 118
DIFFERENT PHASES OF EDLC
●
The life cycle of a product development is commonly referred to
as models.
●
Model defines the various phases involved in the life cycle.
●
The number of phases involved in a model may vary according
to the complexity of the product under consideration.
●
A typical simple product contains five minimal phases namely:
‘Requirement Analysis’, ‘Design’, ‘Development and Test’,
‘Deployment’ and ‘Maintenance’.
●
The classic Embedded Product Life Cycle Model contains the
phases: ‘Need’, ‘Conceptualisation’, ‘Analysis’, ‘Design’,
‘Development and Testing’, ‘Deployment’, ‘Support’, ‘Upgrades’
and ‘Retirement/Disposal’.
●
In a real product development environment, the phases given in
this model may vary and can have submodels or the models
contain only certain important phases of the classic model.

72. 72 / 118

73. 73 / 118
●
Need
– Any embedded product evolves as an output of a ‘Need’.
– The need may come from an individual or from the public or
from a company.
– ‘Need’ should be articulated to initiate the Product
Development Life Cycle and based on the need for the
product, a ‘Statement of Need’ or ‘Concept Proposal’ is
prepared.
– The ‘Concept Proposal’ must be reviewed by the senior
management and funding agency and should get necessary
approval.
– Once the proposal gets approval, it goes to a product
development team, which can either be an organisation
from which the need arise or a third party product
development/service company.
– The product development need can be visualised in any one
of the following three needs.
●
New or Custom Product Development
– The need for a product which does not exist in the
market or a product which acts as competitor to an
existing product in the current market will lead to the
development of a completely new product.

74. 74 / 118
– The product can be a commercial requirement or an
individual requirement or a specific organisation’s
requirement.
– Example for an Embedded Product which acts a
competitor in the current market is ‘Mobile handset’
which is going to be developed by a new company
apart from the existing manufacturers.
– A PDA tailored for any specific need is an example for a
custom product.
●
Product Re-engineering
– The embedded product market is dynamic and
competitive.
– In order to sustain in the market, the product developer
should be aware of the general market trends,
technology changes and the taste of the end user and
should constantly improve an existing product by
incorporating new technologies and design changes for
performance, functionalities and aesthetics.
– Re-engineering a product is the process of making
changes in an existing product design and launching it
as a new version.

75. 75 / 118
– It is generally termed as product upgrade.
– Re-engineering an existing product comes as a result
of the following needs.
●
Product Maintenance
– Product maintenance ‘need’ deals with providing
technical support to the end user for an existing
product in the market.
– The maintenance request may come as a result of
product non-functioning or failure.
– Product maintenance is generally classified into two
categories; Corrective maintenance and Preventive
maintenance.
– Corrective maintenance deals with making corrective
actions following a failure or non-functioning.
– The failure can occur due to damages or non-
functioning of components/parts of the product and
the corrective maintenance replaces them to make
the product functional again.
– Preventive maintenance is the scheduled maintenance
to avoid the failure or non-functioning of the product.

76. 76 / 118
●
Conceptualisation
– Conceptualisation is the ‘Product Concept Development
Phase’ and it begins immediately after a Concept Proposal is
formally approved.
– Conceptualisation phase defines the scope of the concept,
performs cost benefit analysis and feasibility study and
prepares project management and risk management plans.
– Conceptualisation can be viewed as a phase shaping the
“Need” of an end-user or convincing the end user, whether it
is a feasible product and how this product can be realised.

77. 77 / 118
– The ‘Conceptualisation’ phase involves two types of activities,
namely; ‘Planning Activity’ and ‘Analysis and Study Activity’.
– The Analysis and Study Activities are performed to
understand the opportunity of the product in the market (for
a commercial product).
– The following are the important ‘Analysis and Study activities’
performed during ‘Conceptualisation Phase’.
●
Feasibility Study
– Feasibility study examines the need for the product
carefully and suggests one or more possible solutions
to build the need as a product along with alternatives.
– Feasibility study analyses the Technical (Technical
Challenges, limitations, etc.) as well as financial
feasibility (Financial requirements, funding, etc.) of the
product under consideration.
●
Cost Benefit Analysis (CBA)
– The Cost Benefit Analysis (CBA) is a means of
identifying, revealing and assessing the total
development cost and the profit expected from the
product.

78. 78 / 118
– It is somewhat similar to the loss-gain analysis in
business term except that CBA is an assumption
oriented approach based on some rule of thumb or
based on the analysis of data available for similar
products developed in the past.
– CBA estimates and totals up the equivalent money
value of the benefits and costs of the product under
consideration and give an idea about the worthwhile of
the product.
– Some common underlying principles of Cost Benefit
Analysis are illustrated below.
●
Common Unit of Measurement
●
In order to make the analysis sensible and
meaningful, all aspects of the product, either
plus points or minus points should be expressed
in terms of a common unit.
●
Since the ultimate aim of a product is “Marginal
Profit” and the marginal profit is expressed in
terms of money in most cases, ‘money’ is taken
as the common unit of measurement.
●
Hence all benefits and costs of the product
should be expressed in terms of money.

79. 79 / 118
●
Money in turn may be represented by a common
currency.
●
It can be Indian Rupee (INR) or US Dollar (USD),
etc.
●
Market Choice based Benefit Measurement
●
Ensure that the product cost is justifying the
money (value for money), the end user is
spending on the product to purchase, for a
commercial product.
●
Targeted End Users
●
For a commercial product it is very essential to
understand the targeted end- users for the
product and their tastes to give them the best in
the industry.
●
Product Scope
– Product scope deals with what is in scope (what all
functionalities or tasks are considered) for the product
and what is not in scope (what all functionalities or
tasks are not considered) for the product.
– Product scope should be documented properly for
future reference.

80. 80 / 118
●
Planning Activities
– The planning activity covers various plans required for
the product development, like the plan and schedule
for executing the next phases following
conceptualisation,
●
Resource Planning – How many resources should
work on the project,
●
Risk Management Plans – The technical and other
kinds of risks involved in the work
●
and what are the mitigation plans, etc.
– At the end of the conceptualisation phase, the reports
on ‘Analysis and Study Activities’ and ‘Planning
Activities’ are submitted to the client/project sponsor
for review and approval, along with any one of the
following recommendation.
1. The product is feasible; proceed to the next phase
of the product life cycle.
2. The product is not feasible; scrap the project
– The executive committee, to which the various reports
are submitted,
●
will review the same and

81. 81 / 118
●
will communicate the review comments to the
officials submitted the conceptualisation reports and
●
will give the green signal to proceed, if they are
satisfied with the analysis and estimates.
●
Analysis
– Requirements Analysis Phase starts immediately after the
documents submitted during the ‘Conceptualisation’ phase is
approved by the client/ sponsor of the project.
– Documentation related to user requirements from the
Conceptualisation phase is used as the basis for further user
need analysis and the development of detailed user
requirements.
– Requirement analysis is performed to develop a detailed
functional model of the product under consideration.
– During the Requirements Analysis Phase, the product is
defined in detail with respect to the inputs, processes,
outputs, and interfaces at a functional level.
– Requirement Analysis phase gives emphasis on determining
‘what functions must be performed by the product’ rather
than how to perform those functions.

82. 82 / 118
●
Analysis and Documentation
– The analysis and documentation activity consolidates
the business needs of the product under development
and analyses the purpose of the product.
– It addresses various functional aspects (product features
and functions) and quality attributes (non-functional
requirements) of the product, defines the functional and
data requirements and connects the functional
requirements with the data requirements.

83. 83 / 118
– In summary, the analysis activities address all business
functionalities of the product and develop a logical
model describing the fundamental processes and the
data required to support the functionalities.
– The various requirements that need to be addressed
during the requirement analysis phase for a product
under consideration are listed below.
●
1. Functional capabilities like performance,
operational characteristics.
●
2. Operational and non-operational quality attributes
●
3. Product external interface requirements
●
4. Data requirements
●
5. User manuals
●
6. Operational requirements
●
7. Maintenance requirements
●
8. General assumptions
●
Interface Definition and Documentation
– The embedded product under consideration may be a
standalone product or it can be a part of a large
distributed system.

84. 84 / 118
– If it is a part of another system there should be some
interface between the product and the other parts of
the distributed system.
– Even in the case of standalone products there will be
some standard interfaces like serial, parallel etc as a
provision to connect to some standard interfaces.
– The interface definition and documentation activity
should clearly analyse on the physical interface (type
of interface) as well as data exchange through these
interfaces and should document it.
– It is essential for the proper information flow
throughout the life cycle.
●
Defining Test Plan and Procedures
– Identifies what kind of tests are to be performed and
what all should be covered in testing the product.
– Define the test procedures, test setup and test
environment.
– Create a master test plan to cover all functional as well
as other aspects of the product and document the
scope, methodology, sequence and management of all
kinds of tests.

85. 85 / 118
– It is essential for ensuring the total quality of the
product.
– The various types of testing performed in a product
development are listed below.
●
1. Unit testing—Testing each unit or module of the
product independently for required functionality and
quality aspects
●
2. Integration testing—Integrating each modules
and testing the integrated unit for required
functionality
●
3. System testing—Testing the functional
aspects/product requirements of the product after
integration.
●
System testing refers to a set of different tests and
a few among them are listed below.
●
Usability testing—Tests the usability of the
product
●
Load testing—Tests the behaviour of the product
under different loading conditions.
●
Security testing—Testing the security aspects of
the product

86. 86 / 118
●
Scalability testing—Testing the scalability aspect
of the product
●
Sanity testing—Superficial testing performed to
ensure that the product is functioning properly
●
Smoke testing—Non exhaustive test to ensure
that the crucial requirements for the product are
functioning properly. This test is not giving
importance to the finer details of different
functionalities
●
Performance testing—Testing the performance
aspects of the product after integration
●
Endurance testing—Durability test of the product
●
4. User acceptance testing—Testing the product to
ensure it is meeting all requirements of the end
user.
– At the end, all requirements should be put in a
template suggested by the standard Process Model
followed for the Quality Assurance.
– This document is referred as ‘Requirements
Specification Document’.

87. 87 / 118
– It is sent out for review by the client and the client,
after reviewing the requirements specification
document, communicates back with the review
comments.
– According to the review comments more requirement
analysis may have to be performed and re-work
required is performed on the initial ‘Requirement
Specification Document’.
●
Design
– Product ‘Design phase’ deals with the entire design of the
product taking the requirements into consideration and it
focuses on ‘how’ the required functionalities can be delivered
to the product.
– The design phase identifies the application environment and
creates an overall architecture for the product.
– Product design starts with ‘ Preliminary Design/High Level
Design’.
– Preliminary design establishes the top-level architecture for
the product, lists out the various functional blocks required
for the product, and defines the inputs and outputs for each
functional block.

88. 88 / 118
– The functional block will look like a ‘black box’ at this design
point, with only inputs and outputs of the block being
defined.
– On completion, the ‘Preliminary Design Document (PDD) is
sent for review to the end-user/client who come up with a
need for the product.
– If the end-user agrees on the preliminary design, the product
design team can take the work to the next level – ‘ Detailed
Design’.
– Detailed design generates a detailed architecture, identifies
and lists out the various components for each functional
block, the inter connection among various functional blocks,
the control algorithm requirements, etc.
– The ‘Detailed Design’ also needs to be reviewed and get
approved by the end user/customer.
– If the end user wants modifications on the design, it can be
informed to the design team through review comments.
– An embedded product is a real mix of hardware, embedded
firmware and enclosure.
– Hence both Preliminary Design and Detailed Design should
take the design of these into consideration.

89. 89 / 118
– For traditional embedded system design approach, the
functional requirements are classified into either hardware or
firmware at an early stage of the design and the hardware
team works on the design of the required hardware, whereas
the software team works on the design of the embedded
firmware.
– Today the scenario is totally changed and a hardware
software co-design approach is used.
– In this approach, the functional requirements are not broken
down into hardware and software, instead they are treated
as system requirements and the partitioning of system
requirements into either hardware or software is performed
at a later stage of the design based on hardware-software
trade-offs for implementing the required functionalities.
– The hardware and software requirements are modelled using
different modelling techniques.
– The other activities performed during the design phase are
‘Design of Operations and maintenance manual’ and ‘Design
of Training materials’ .

90. 90 / 118
– The operations manual is necessary for educating the end
user on ‘how to operate the product’ and the maintenance
manual is essential for providing information on how to handle
the product in situations like non-functioning, failure, etc.

91. 91 / 118

92. 92 / 118
●
Development and Testing
– The ‘Development Phase’ transforms the design into a
realisable product.
– For this the detailed specifications generated during the
design phase are translated into hardware and firmware.
– During development phase, the installation and setting up of
various development tools is performed and the product
hardware and firmware is developed using different tools and
associated production setup.
– The development activities can be partitioned into embedded
hardware development, embedded firmware development
and product enclosure development.
– Embedded hardware development refers to the development
of the component placement platform – PCB using CAD tools
and its fabrication using CAM Tools.
– Embedded firmware development is performed using the
embedded firmware development tools.
– The mechanical enclosure design is performed with CAD Tools
like Solid Works, AutoCAD, etc.

93. 93 / 118
– “Look and Feel” of a commercial product plays an important
role on its market demand.
– So the entire product design and development should
concentrate on the product aesthetics (Size, Weight,
Appearance, etc.) and special requirements like protection
shielding, etc.
– Component procurement also carried out during this phase.
– Some of the components may have “lead time – The time
required for the component to deliver after placing the
purchase order for the component” and the component
procurement should be planned well in advance to avoid the
possible delay in the product development.
– The other important activities carried out during this phase
are preparation of test case procedures, preparation of test
files and development of detailed user, deployment,
operations and maintenance manual.
– The embedded firmware development may be divided into
various modules and the firmware (code) review for each
module as well as the schematic diagram and layout file
review for hardware is carried out during the development
phase and the changes required should be incorporated in
the development from time to time.

94. 94 / 118
– The testing phase can be divided into
●
independent testing of firmware and hardware ( Unit
Testing),
●
testing of the product after integrating the firmware and
hardware ( Integration Testing),
●
testing of the whole system on a functionality and non-
functionality basis ( System Testing)
●
testing of the product against all acceptance criteria
mentioned by the client/end user for each functionality
(User Acceptance Testing).
– The Unit testing deals with testing the embedded hardware
and its associated modules, the different modules of the
firmware for their functionality independently.
– A test plan is prepared for the unit testing (Unit Test plan)
and test cases (Unit Test cases) are identified for testing the
functionality of the product as per the design.
– Unit test is normally performed by the hardware developer or
firmware developer as part of the development phase.
– Depending on the product complexity, rest of the tests can
be considered as the activities performed in the ‘Testing
phase’ of the product.

95. 95 / 118
– Once the hardware and firmware are unit tested, they are
integrated using various firmware integration techniques and
the integrated product is tested against the required
functionalities.
– An integration test plan is prepared for this and the test cases
for integration testing (Integration test cases) is developed.
– The Integration testing ensures that the functionality which is
tested working properly in an independent mode remains
working properly in an integrated product (Hardware +
Firmware).
– The integration test results are logged in and the firmware
/hardware is reworked against any flaws detected during the
Integration testing.
– The purpose of integration testing is to detect any
inconsistencies between the firmware modules units that are
integrated together or between any of the firmware modules
and the embedded hardware.
– Integration testing of various modules, hardware and
firmware is done at the end of development phase depending
on the readiness of hardware and firmware.

96. 96 / 118
– The system testing follows the Integration testing and it is a
set of various tests for functional and non-functional
requirements verification.
– System testing is a kind of black box testing, which doesn’t
require any knowledge on the inner design logic or code for
the product.
– System testing evaluates the product’s compliance with the
requirements.
– User acceptance test or simply Acceptance testing is the
product evaluation performed by the customer as a condition
of the product purchase.
– During user Acceptance testing, the product is tested against
the acceptance value set by customer/end user for each
requirement.
– The deliverables from the ‘Design and Testing’ phase are
firmware source code, firmware binaries, finished hardware,
various test plans, test cases and test reports.

97. 97 / 118
●
Deployment
– Deployment is the process of launching the first fully
functional model of the product in the market (for a
commercial embedded product) or handing over the fully
functional initial model to an end user/client.
– It is also known as First Customer Shipping (FCS).
– During this phase, the product modifications as per the
various integration tests are implemented and the product is
made operational in a production environment.
– The ‘Deployment Phase’ is initiated after the system is
tested and accepted (User Acceptance Test) by the end user.
– The important tasks performed during the Deployment
Phase are listed below.
●
Notification of Product Deployment
– Whenever the product is ready to launch in the
market, the launching ceremony details should be
communicated to the stake holders and to the public if
it is a commercial product.
– The notifications can be sent out through e-mail,
media, etc. mentioning the following in a few words.
●
1. Deployment Schedule (Date Time and Venue)

98. 98 / 118
●
2. Brief description about the product
●
3. Targeted end users
●
4. Extra features supported with respect to an
existing product
●
5. Product support information including the
support person name, contact number, contact
mail ID, etc.
●
Execution of Training Plan
– Proper training should be given to the end user to get
them acquainted with the new product.
– Before launching the product, conduct proper training
as per the training plan developed during the earlier
phases.
– Proper training will help in reducing the possible
damages to the product as well as the operating
person, including personal injuries and product mal-
functioning due to inappropriate usage.
– User manual will help in understanding the product, its
usage and accessing its functionalities to certain
extend.

99. 99 / 118
●
Product Installation
– Instal the product as per the installation document to
ensure that it is fully functional.
– As a typical example take the case of a newly
purchased mobile handset.
– The user manual accompanying it will tell you clearly
how to instal the battery, how to charge the battery,
how many hours the battery needs to be charged, how
the handset can be switched on/off, etc.
●
Product Post-Implementation Review
– Once the product is launched in the market, conduct a
post-implementation review to determine the success
of the product.
– The ultimate aim behind post-implementation review
is to document the problems faced during installation
and the solutions adopted to overcome them which
will act as a reference document for future product
development.
– It also helps in understanding the customer needs and
the expectations of the customer on the next version
of the product.

100. 100 / 118
●
Support
– The support phase deals with the operations and
maintenance of the product in a production environment.
– During this phase all aspects of operations and maintenance
of the product are covered and the product is scrutinised to
ensure that it meets the requirements put forward by the
end user/client.
– ‘Bugs (product mal-functioning or unexpected behaviour or
any operational error)’ in the products may be observed and
reported during the operations phase.
– Support should be provided to the end user/client to fix the
bugs in the product.
– The support phase ensures that the product meets the user
needs and it continues functioning in the production
environment.
– The various activities involved in the ‘Support’ phase are
listed below.
●
Set up a Dedicated Support Wing
– The availability of certain embedded products in terms
of product functioning in production environment is
crucial and they may require 24x7 support in case of
product failure or malfunctioning.

101. 101 / 118
– For example the patient monitoring system used in
hospitals is a very critical product in terms of
functioning and any malfunctioning of the product
requires immediate technical attention/support from
the supplier.
– Set up a dedicated support wing (customer care unit)
and ensure high quality service is delivered to the end
user.
– ‘After service’ plays significant role in product
movement in a commercial market.
– If the manufacturer fails to provide timely and quality
service to the end user, it will naturally create the talk
‘the product is good but the after service is very poor’
among the end users and people will refrain from
buying such products and will opt for competitive
products which provides more or less same
functionalities and high quality service.
– The support wing should be set up in such a way that
they are easily reachable through e-mail, phone, fax,
etc.

102. 102 / 118
●
Identify Bugs and Areas of Improvement
– None of the products are bug-free.
– Even if you take utmost care in design, development
and implementation of the product, there can be bugs
in it and the bugs reveal their real identity when the
conditions are favouring them, similar to the harmless
microbes living in human body getting turned into
harmful microbes when the body resistance is weak.
– You may miss out certain operating conditions while
design or development phase and if the product faces
such an operating condition, the product behaviour
may become unexpected and it is addressed with the
familiar nick name ‘Bug’ by a software/product
engineer.
– Since the embedded product market is highly
competitive, it is very essential to stay connected with
the end users and know their needs for the survival of
the product.
– Give the end user a chance to express their views on
the product and suggestions, if any, in terms of
modifications required or feature enhancements (areas
of improvement), through user feedbacks.

103. 103 / 118
– Conduct product specific surveys and collect as much
data as possible from the end user.
●
Upgrades
– The upgrade phase of product development deals with the
development of upgrades (new versions) for the product
which is already present in the market.
– Product upgrade results as an output of major bug fixes or
feature enhancement requirements from the end user.
– During the upgrade phase the system is subject to design
modification to fix the major bugs reported or to incorporate
the new feature addition requirements aroused during the
support phase.
– For embedded products, the upgrades may be for the product
resident firmware or for the hardware embedding the
firmware.
– Some bugs may be easily fixed by modifying the firmware
and it is known as firmware up-gradation.
– Some feature enhancements can also be performed easily by
mere firmware modification.

104. 104 / 118
– The product resident firmware will have a version number
which starts with version say 1.0 and after each firmware
modification or bug fix, the firmware version is changed
accordingly.
– Version numbering is essential for backward traceability.
– Releasing of upgrades is managed through release
management.
– Certain feature enhancements and bug fixes require hardware
modification and they are generally termed as hardware
upgrades.
– Firmware also needs to be modified according to the hardware
enhancements.
– The upgraded product appears in the market with the same
name as that of the initial product with a different version
number or with a different name.
●
Retirement/Disposal
– Due to increased user needs and revolutionary technological
changes, a product cannot sustain in the market for a long
time.
– The disposal/retirement of a product is a gradual process.

105. 105 / 118
– When the product manufacture realises that there is another
powerful technology or component available in the market
which is most suitable for the production of the current
product, they will announce the current product as obsolete
and the newer version/upgrade of the same is going to be
released soon.
– The retirement/disposition phase is the final phase in a
product development life cycle where the product is declared
as obsolete and discontinued from the market.
– There is no meaning and monetary benefit in continuing the
production of a device or equipment which is obsolete in
terms of technology and aesthetics.
– The disposition of a product is essential due to the following
reasons.
●
1. Rapid technology advancement
●
2. Increased user needs
– Some products may get a very long ‘Life Time’ in the market,
beginning from the launch phase to the retirement phase and
during this time the product will get reasonably good amount
of maturity and stability and it may be able to create
sensational waves in the market.

106. 106 / 118
MODELING THE EDLC
●
Linear or Waterfall Model
– Linear or waterfall approach is the one adopted in most of
the olden systems and in this approach each phase of EDLC
is executed in sequence.
– The linear model establishes a formal analysis and design
methodology with highly structured development phases.
– In linear model, the various phases of EDLC are executed in
sequence and the flow is unidirectional with output of one
phase serving as the input to the next phase.
– In the linear model all activities involved in each phase are
well documented, giving an insight into what should be done
in the next phase and how it can be done.
– The feedback of each phase is available locally and only after
they are executed.
– The linear model implements extensive review mechanisms
to ensure the process flow is going in the right direction and
validates the effort during a phase.

107. 107 / 118
– One significant feature of linear model is that even if you
identify bugs in the current design, the corrective actions are
not implemented immediately and the development process
proceeds with the current design.
– The fixes for the bugs are postponed till the support phase,
which accompanies the deployment phase.
– The major advantage of ‘Linear Model’ is that the product
development is rich in terms of documentation, easy project
management and good control over cost and schedule.
– The major drawback of this approach is that it assumes all
the analysis can be done and everything will be in right
place without doing any design or implementation.
– Also the risk analysis is performed only once throughout the
development and risks involved in any changes are not
accommodated in subsequent phases, the working product is
available only at the end of the development phase and bug
fixes and corrections are performed only at the
maintenance /support phase of the life cycle.
– ‘Linear Model’ is best suited for product developments,
where the requirements are well defi ned and within the
scope, and no change requests are expected till the
completion of the life cycle

108. 108 / 118

109. 109 / 118
●
Iterative/ Incremental or Fountain Model
– Iterative or fountain model follows the sequence—Do some
analysis, follow some design, then some implementation.
– Evaluate it and based on the shortcomings, cycle back
through and conduct more analysis, opt for new design and
implementation and repeat the cycle till the requirements are
met completely.
– The iterative/fountain model can be viewed as a cascaded
series of linear (waterfall) models.
– The incremental model is a superset of iterative model where
the requirements are known at the beginning and they are
divided into different groups.
– The core set of functions for each group is identified in the
first cycle and is built and deployed as the first release.
– The second set of requirements along with the bug fixes and
modification for first release is carried out in the second cycle
and the process is repeated until all functionalities are
implemented and they are meeting the requirements. It is
obvious that in an iterative/incremental model each
development cycle act as the maintenance phase for the
previous cycle (release).

110. 110 / 118
– Another approach for the iterative/interactive model is the
‘Overlapped’ model where development cycles overlap;
meaning subsequent iterative/incremental cycle may begin
before the completion of previous cycle.

111. 111 / 118
– If you closely observe this model you can see that each cycle
is interconnected in a similar fashion of a fountain, where
water first moves up and then comes down, again moves up
and comes down.
– The major advantage of iterative/fountain model is that it
provides very good development cycle feedback at each
function/feature implementation and hence the data can be
used as a reference for similar product development in future.
– Since each cycle can act as a maintenance phase for previous
cycle, changes in feature and functionalities can be easily
incorporated during the development and hence more
responsive to changing user needs.
– The iterative model provides a working product model with at
least minimum features at the first cycle itself.
– Risk is spread across each individual cycle and can be
minimised easily.
– Project management as well as testing is much simpler
compared to the linear model.
– Another major advantage is that the product development
can be stopped at any stage with a bare minimum working
product.

112. 112 / 118
– Though iterative model is a good solution for product
development, it possess lots of drawbacks like extensive
review requirement at each cycle, impact on operations due
to new releases, training requirement for each new
deployment at the end of each development cycle,
structured and well documented interface definition across
modules to accommodate changes.
– The iterative/incremental model is deployed in product
developments where the risk is very high when the
development is carried out by linear model.
– By choosing an iterative model, the risk is spread across
multiple cycles.
– Since each cycle produces a working model, this model is
best suited for product developments where the continued
funding for each cycle is not assured.
●
Prototyping/Evolutionary Model
– Prototyping/ evolutionary model is similar to the iterative
model and the product is developed in multiple cycles.