S8-CST464-Embedded Systems

(2019 Scheme)

Reenu Renjith
Assistant Professor CSE-MBITS
 Module - 4 (Embedded Firmware Design and
Development, and EDLC )
• 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.
Embedded Firmware Design and Development
• Embedded firmware is a specialized type of software that is permanently
programmed into a hardware device to control its functions.
• Firmware is considered as the master brain of the embedded system.
• For most of the embedded products the embedded firmware is stored at a
permanent memory (ROM) and they are non-alterable by end users.
• Embedded firmware design and development is the process of creating software
that directly controls hardware devices (microcontrollers, sensors, actuators) to
perform specific functions in embedded systems.
 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 are:
• The Super Loop Based Approach
• The Embedded Operating System (OS) Based Approach
 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.
• They are used in embedded systems where missing deadlines are acceptable.
• 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.
• 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. 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

• 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.
• A hardware reset brings the program execution back to the main loop.
• An interrupt request suspends the task execution temporarily, then performs
the interrupt routine and on completion of the interrupt routine it restarts
the task execution.
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.
• 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.
• It contains a Real Time kernel responsible for performing pre-emptive
multitasking, scheduler for scheduling tasks, multiple threads, etc.
• It allows flexible scheduling of system resources like the CPU and memory and
offers some way to communicate between tasks.
• examples of RTOS employed in embedded product development -
• ‘Windows Embedded Compact’, ‘pSOS’, ‘VxWorks’, ‘ThreadX’, ‘MicroC/OS-III’,
‘Embedded Linux’, ‘Symbian’ etc are
 Embedded OS (RTOS) Based
Feature Super Loop Based Approach
Approach
System executes tasks repeatedly in a System uses an operating system
Definition
single infinite loop kernel to manage multiple tasks
OS-based (RTOS or Embedded OS
Architecture Bare-metal (no OS)
present)
Concurrent / multitasking (tasks
Task Execution Sequential execution (one task at a time)
scheduled by OS)
Automatic scheduling (priority, time
Scheduling Manual control by programmer
slicing, deadlines)

Complexity Simple to design and implement More complex

Memory Requirement Very low Higher (kernel + task stacks)
Faster and predictable real-time
Response Time Slower for time-critical tasks
response
Reliability Suitable for small systems High reliability for complex systems
Development Cost Low Higher
EMBEDDED FIRMWARE DEVELOPMENT LANGUAGES
• For embedded firmware development you can use either (Assembly language/low level
language) or (High Level Language) or a combination of both Assembly and High level
Language.
• Machine language is the lowest-level language made up of 0s and 1s (binary) that
the computer directly understands.
• Assembly language is a low-level language that uses mnemonics (short English
words) instead of binary. It is converted to machine language using an Assembler.
• High-level language is a user-friendly programming language that is easy to read,
write, and understand.
• Examples: C, C++, Java, Python.
• Based on this embedded firmware development languages can be classified as:
• Assembly Language based Development
• High Level Language Based Development
• Mixing Assembly and High Level Language
 Assembly Language based Development

• 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.
• Conversion of the assembly language to machine language is carried out by a
sequence of operations, as illustrated:
• Source File to Object File Translation
• Library File Creation and Usage
• Linker and Locator
• Object to Hex File Converter
• The various steps involved in the conversion of a program written in assembly
language to corresponding binary file/machine language is illustrated in Fig. 9.1.
• Source File to Object File Translation
• Each source module is written in Assembly and is stored as .src file or .asm file.
• On successful assembling of each .src/.asm file a corresponding object file is created with
extension ‘.obj’.
• 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.
• 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’.
• 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
and those obj files created by the assembler.
• Object to Hex File Converter
• This is the final stage in the conversion of Assembly language to machine language.
• Hex File is the representation of the machine code and the hex file is dumped into the code
memory of the processor/controller.
• Advantages of Assembly Language Based Development

• 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.
• High Performance
• Optimised code not only improves the code memory usage but also improves
the total system performance.
• Low Level Hardware Access
• low level device specific operation support is not commonly available with most
of the high-level language cross compilers.
• Code Reverse Engineering
• Reverse engineering is the process of understanding the technology behind a
product by extracting the information from a finished product. It may be
possible to 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

• High Development Time

• Assembly language is much harder to program than high level languages. The
developer must pay attention to more details and it is highly time consuming
and it creates a delay impact in product development.
• Developer Dependency
• There is no common written rule for developing assembly language based
applications. If the approach done by a developer is not documented properly,
then the developer may not be able to recollect why this approach was 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.
• Non-Portable
• Target applications written in assembly instructions are valid only for that
particular family of processors and cannot be re-used. If the target changes a
complete re-writing is required.
 High Level Language Based Development
• Assembly language based programming :
• highly time consuming
• requires skilled programmers
• non-portable
• Any high level language (like C, C++ or Java) with a supported cross compiler for
the target processor can be used for embedded firmware development.
• 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.
• The various steps involved in the conversion of a program written in high level
language to corresponding binary file/machine language is illustrated in Fig. 9.2.
• The program written in any of the high level language is saved with the
corresponding language extension (.c for C, .cpp for C++, etc).
• Any text editor tool supporting the high level language in use can be used for
writing the program.
• 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.
• 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, hence reduced development
time.
• 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
• Portability
• Target applications written in high level languages are converted to target
machine codes by a cross-compiler. An application written in high level language
can easily be converted with little effort.

• Limitations of High Level Language Based Development

• Some cross compilers available for high level languages may not be so efficient.
 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:
• Mixing Assembly Language with High Level Language
• Mixing High Level Language with Assembly Language
• In-line Assembly
• Mixing Assembly Language with High Level Language
• 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
• the programmer wants to take advantage of the speed and optimised
code offered by machine code
• 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.
• Mixing High Level Language with Assembly
• Mixing the code written in a high level language like ‘C’ and Assembly
language is useful in the following scenarios:
• 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.
• The entire source code is planned in Assembly code for various reasons
like optimised code, optimal performance, etc.. But some portions of the
code may be very difficult and tedious to code in Assembly.
• For example 16 bit multiplication and division in 8051 Assembly
Language.
• 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’.
• In-line 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’.
• This avoids the delay in calling an assembly routine from a ‘C’ code.
• Special keywords are used to indicate that the start and end of Assembly
instructions.
• The keywords are cross-compiler specific.
• C51 uses the keywords #pragma asm and #pragma endasm to indicate a block
of code written in assembly.
 Integration of Embedded 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.
• If the processor has internal code memory and the firmware size fits, the
program is stored directly inside the processor.
• If there is no internal memory or the firmware is too large, an external
EPROM/Flash memory chip is used to store the program.
• Firmware embedding techniques for a non-OS based embedded system are :
• Out-of-Circuit Programming
• In System Programming (ISP)
• In Application Programming ( IAP)
• Use of Factory Programmed Chip
• 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 (Fig. 12.1).
• The programming device is a dedicated unit
which contains the necessary hardware circuit
to generate the programming signals.
• 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.
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
2. Power up the device
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
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
• 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.
• In order to perform ISP operations the target device 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.
• 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 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.
• Thus it is possible for an end-user application to perform operations on the
Flash memory.
• 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.
• OS based embedded systems contain a special piece of code called ‘Boot
loader’ program which takes control of the OS, application firmware
embedding and copying of the OS image to the RAM.
• The ‘ Boot loader’ for such embedded systems comes as pre-loaded or it can
be loaded to the memory.
• Bootloader implements menu options for selecting the source for OS image to
load.
• 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.
 Embedded Product Development Life Cycle
(EDLC)
• Embedded Product Development Life Cycle is an ‘Analysis-Design-
Implementation’ based standard problem-solving approach for
Embedded Product Development.
• 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.
• 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.
 (EDLC) - Objectives
• EDLC has three primary objectives:
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.
1. Ensure that high quality products are delivered to end user.
• 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 product
development is based on the assumption that the product will produce a
good return or a return justifying the investment.
• 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.
2. Risk minimisation and defect prevention in product development
through project management.
• There are projects in embedded product development which requires ‘loose’
or ‘tight’ project management.
• Loose - If the product development project is a simple one, a senior developer itself can
take charge of the management activity.
• Tight - Projects which are complex and requires timeliness should have a dedicated and
skilled project management part.
• ‘ Project management is essential for predictability, co-ordination and risk
minimisation’.
• aspects of predictability
• 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.
• Resource (Developer) allocation is another aspect of predictability in management.
3. Maximise the 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.
• Productivity in terms of Returns is said to be increased, if the product is
capable of yielding maximum returns with reduced investment.
 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 9 phases:
• Need
• Conceptualisation
• Analysis
• Design
• Development and Testing
• Deployment
• Support
• Upgrades
• Retirement/Disposal
1️⃣ Need
• A problem or market requirement is identified.
• Example: Need for a smart energy-saving home device.
2️⃣ Conceptualisation
• Initial idea is created to solve the need.
• Basic features and feasibility are discussed.
3️⃣ Analysis
• Detailed study of requirements.
• Cost, hardware selection, risks, and feasibility are analyzed.
4️⃣ Design
• System architecture is prepared.
• Hardware design and firmware/software design are planned.
5️⃣ Development and Testing
• Actual coding and hardware development happen.
• Unit testing, integration testing, and system testing are performed.
6️⃣ Deployment
• Product is released to customers.
• Installation and commissioning are done.
7️⃣ Support
• Maintenance and bug fixing.
• Customer service and technical assistance.
8️⃣ Upgrades
• Feature enhancements or performance improvements.
• Firmware updates or hardware revisions.
9️⃣ Retirement / Disposal
• Product is withdrawn from market.
• Safe disposal or recycling of electronic components.
1) Need
• Any embedded product evolves as an output of a ‘Need’.
• ‘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 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.
• Product Re-engineering - Re-engineering a product is the process of making
changes in an existing product design and launching it as a new version. It is
generally termed as product upgrade. Re-engineering an existing product comes
as a result of the following needs:
• 1. Change in Business requirements
• 2. User Interface Enhancements
• 3. Technology Upgrades
• Product Maintenance - Product maintenance ‘need’ deals with providing
technical support to the end user for an existing product in the market.
2) Conceptualisation
• Conceptualisation is the ‘Product Concept Development Phase’ and it begins immediately
after a Concept Proposal is formally approved.
• 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
realized.
• The ‘Conceptualisation’ phase involves two types of activities:
• Planning Activity
• Analysis and Study Activity
• The following are the important ‘Analysis and Study activities’ performed:
• 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.
• 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.
• Product Scope - Product scope deals with what is in scope for the
product and what is not in scope for the product.
• Planning Activities - The planning activity covers various plans
required for the product development, like Resource Planning, Risk
Management Plans, etc.
3) Analysis
• Requirements Analysis Phase starts
immediately after the documents
submitted during the
‘Conceptualisation’ phase is approved
by the client.
• 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.
• The various activities performed during ‘Requirement Analysis’ phase are:
• Analysis and Documentation
• Interface Definition and Documentation
• Defining Test Plan and Procedures

• Analysis and Documentation - The analysis and documentation activity

consolidates the business needs of the product under development and analyses
the purpose of the product. The various requirements that need to be addressed
during the requirement analysis phase are:
• 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 part of a large distributed system. If so, there should be
some interface.
• 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. The various types of testing
performed in a product development are listed below:
• 1. Unit testing
• 2. Integration testing
• 3. System testing
• 4. User acceptance testing
4) 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.
• 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.
• On completion, the ‘Preliminary Design Document (PDD) is sent for review to the
client.
• 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
• It 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 client.
5) 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
• product enclosure development
• 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).
6) Deployment
• Deployment is the process of launching the first fully functional model of the
product in the market or handing over the fully functional initial model to a
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.
• 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.
• Product Installation – Install the product as per the installation document to
ensure that it is fully functional.
• Product Post-Implementation Review - Once the product is launched in the
market, conduct a post-implementation review to determine the success of
the product.
7) 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.
• The various activities involved in the ‘Support’ phase are listed below:
• Set up a Dedicated Support Wing
• Certain embedded products may require 24x7 support in case of product failure
or malfunctioning.
• Set up a dedicated support wing (customer care unit) and ensure high quality
service is delivered to the end user.
• 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.
• 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.
• Conduct product specific surveys and collect as much data as possible from the
end user.
8) 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.
• 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 (e.g. version 1.1).
• Version numbering is essential for backward traceability.
9) Retirement/Disposal
• 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:
• Rapid technology advancement
• Increased user needs
 Modeling Techniques - EDLC APPROACHES
• The various approaches adopted or models used in Modelling EDLC are :
• Linear or Waterfall Model
• Iterative/ Incremental or Fountain Model
• Prototyping/Evolutionary Model
• Spiral Model
 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.
• establishes a formal analysis and design methodology with highly structured
development phases.
• the flow is unidirectional with output of one phase serving as the input to the
next phase.
• 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.
• 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.
• 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 drawbacks 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.
• the risk analysis is performed only once throughout the development
• the working product is available only at the end of the development phase
• 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
defined and within the scope, and no change requests are expected till the completion
of the life cycle.
 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).
• Major advantages:
• It provides very good development cycle feedback at each stage of
implementation.
• The product development can be stopped at any stage with a bare minimum
working product.

• 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.
• The only difference is that this model produces a more refined prototype of the product at
the end of each cycle.
• There won’t be any commercial deployment of the prototype of the product at each cycle’s
end.
• The shortcomings of the proto-model after each cycle are evaluated and it is fixed in the next
cycle.
• Steps
• After the initial requirement analysis, the design for the first prototype is made, the
development process is started.
• On finishing the prototype, it is sent to the customer for evaluation. The customer
evaluates the product for the set of and gives feedback to the developer.
• The developer refines the product according to the customer’s exact expectation and
repeats the proto development process.
• After a finite number of iterations, the final product is delivered to the customer and
launched in the market.
• Advantages
• Since the requirements undergo refinement after stage, it is easy to incorporate new
requirements and technology changes at any stage
• relies heavily on user feedback after each implementation and hence finetuning of
final requirements is possible.
• risk is spread across each proto development cycle and it is well under control.
• The major drawbacks of proto-typing model are:
• Deviations from expected cost and schedule due to requirements refinement
• Increased project management
• Minimal documentation on each prototype may create problems in backward
prototype traceability
• Increased Configuration Management activities
• In short
• most popular product development model.
• best approach for products, whose requirements are not fully available and are
subject to change.
• not recommended for projects involving the upgradation of an existing product.
 Spiral Model
• Spiral model combines the elements of linear and prototyping models to give the
best possible risk minimised EDLC Model.
• Spiral model was developed by Barry Boehm in 1988.
• The product development starts with project definition and traverse through all
phases of EDLC through multiple phases.
• The activities involved in the Spiral model can be associated with the four
quadrants of a spiral and are listed below.
1. Determine objectives, alternatives and constraints.
2. Evaluate alternatives, Identify and resolve risks.
3. Develop and test.
4. Plan.
 Textbooks
• K. V. Shibu, Introduction to Embedded Systems, McGraw Hill
Education, Second Edition, 2017.
• James K. Peckol, Embedded Systems: A Contemporary Design Tool,
John Wiley & Sons, Second Edition, 2019.
• Marilyn Wolf, Computers as Components-Principles of Embedded
Computing System Design, Morgan Kaufmann, Elsevier, Fourth
Edition, 2016.