UNIT 5

EMBEDDED SYSTEM DESIGN AND DEVELOPMENT

LIFE CYCLE MODELS

The fundamentals of design are

Find out what the customers want.

Think of a way to give them what they want.
Prove what you have done by building and testing it.
Build a lot of the product to prove that it wasn‘t an accident.
Use the product to solve the customer‘s problem.

The common life cycle models are:

Waterfall model
V cycle model.
Spiral
Rapid prototype

Waterfall model

The waterfall model represents a cycle- specifically a series of steps appearing much like a
waterfall. It is the model which is use to linear process development. It is a sequential design
process, often used in software process development in which progress is seen as flowing
steadily downwards through the phases of Conception, Initiation, Analysis, Design,
Construction, Testing, Production/Implementation and Maintenance. Figure 4.1 shows the water
life cycle model
 Figure 4.1 The waterfall life cycle model

The waterfall development model originates in the manufacturing and construction

industries: highly structured physical environments in which after-the-fact changes are
prohibitively costly, if not impossible. Since no formal software development methodologies
existed at the time, this hardware-oriented model was simply adapted for software development.

The steps are:

Specification.
Preliminary design.
Design review
Detailed design.
Design review.
Implementation.
Review.
Phases:

1) Requirement : In this phase we gather necessary information which will use for
development of any project . For above example we gather information like which types of
characteristics client wants. It also defines system requirement specification. This phase defines
what to do.

2) Design: In design phase we then construct design to how to implement that requirements
gathered into phase 1 .This phase define how to do .For this phase we then write algorithms

3) Coding: Now base on design phase we then write actual code to implement algorithms. This
code should be efficient.

4)Testing : This phase use to test our coding part it checks all the validation...like our code
should work for each and every possibilities of input if any bug occur then we have to report that
bug to design phase or development phase.

5) Maintenance: In this phase we need keep updating information.

1. The implementation process contains software preparation and transition activities, such as the
conception and creation of the maintenance plan; the preparation for handling problems
identified during development; and the followup on product configuration management.

2. The problem and modification analysis process, which is executed once the application has
become the responsibility of the maintenance group. The maintenance programmer must analyze
each request, confirm it (by reproducing the situation) and check its validity, investigate it and
propose a solution, document the request and the solution proposal, and, finally, obtain all the
required authorizations to apply the modifications.

3. The process considering the implementation of the modification itself.

4. The process acceptance of the modification, by confirming the modified work with the
individual who submitted the request in order to make sure the modification provided a solution.
EMBEDDED SYSTEM DESIGN 10EC74

5. The migration process is exceptional, and is not part of daily maintenance tasks. If the
software must be ported to another platform without any change in functionality, this process
will be used and a maintenance project team is likely to be assigned to this task.

6. Finally, the last maintenance process, also an event which does not occur on a daily basis, is
the retirement of a piece of software.

The V model

The V-Model is a term applied to a range of models, from a conceptual model designed to
produce a simplified understanding of the complexity associated with systems development to
detailed, rigorous development lifecycle models and project management models. Each test
phase is identified with its matching development phase as shown in figure 4.2.

Figure 4.2 : The V life cycle model

In diagram, we have

Requirement system/Functional Testing

High level design Integration testing

Dept of ECE,GCEM Page 61

EMBEDDED SYSTEM DESIGN 10EC74

Detailed design Unit testing

The V-model is a graphical representation of the systems development lifecycle. It summarizes

the main steps to be taken in conjunction with the corresponding deliverables within
computerized system validation framework.

The V represents the sequence of steps in a project life cycle development. It describes the
activities to be performed and the results that have to be produced during product development.
The left side of the "V" represents the decomposition of requirements, and creation of system
specifications. The right side of the V represents integration of parts and their validation

Validation. The assurance that a product, service, or system meets the needs of the customer
and other identified stakeholders. It often involves acceptance and suitability with external
customers. Contrast with verification."
"Verification. The evaluation of whether or not a product, service, or system complies with a
regulation, requirement, specification, or imposed condition. It is often an internal process.
Contrast with validation."
The spiral model

The spiral model is a software development process combining elements of

both design and prototyping-in-stages, in an effort to combine advantages of top-down and
bottom-up concepts. Also known as the spiral lifecycle model (or spiral development), it is a
systems development method (SDM) used in information technology (IT). This model of
development combines the features of the prototyping and the waterfall model. The spiral model
is intended for large, expensive and complicated projects. A simplified version of that model is
presented in figure 4.3.
 Figure 4.3 The spiral life cycle model steps

The steps in spiral model life cycle are

Determine objective,alternatives,and constraints.

Identify and resolve risks.
Evaluate alternatives.
Develop deliverables-verify that they are correct.
Plan the next iteration.
Commit to an approach for the next iteration.
The spiral model combines the idea of iterative development (prototyping) with the systematic,
controlled aspects of the waterfall model. It allows for incremental releases of the product, or
incremental refinement through each time around the spiral. The spiral model also explicitly
includes risk management within software development. Identifying major risks, both technical
and managerial, and determining how to lessen the risk helps keep the software development
process under control.
The spiral model is based on continuous refinement of key products for requirements definition
and analysis, system and software design, and implementation (the code). At each iteration
around the cycle, the products are extensions of an earlier product. This model uses many of the
same phases as the waterfall model, in essentially the same order, separated by planning, risk
assessment, and the building of prototypes and simulations

Documents are produced when they are required, and the content reflects the information
necessary at that point in the process. All documents will not be created at the beginning of the
process, nor all at the end (hopefully). Like the product they define, the documents are works in
progress. The idea is to have a continuous stream of products produced and available for user
review.

The spiral lifecycle model allows for elements of the product to be added in when they become
available or known. This assures that there is no conflict with previous requirements and design.
This method is consistent with approaches that have multiple software builds and releases and
allows for making an orderly transition to a maintenance activity. Another positive aspect is that
the spiral model forces early user involvement in the system development effort. For projects
with heavy user interfacing, such as user application programs or instrument interface
applications, such involvement is helpful

Note that the requirements activity takes place in multiple sections and in multiple iterations, just
as planning and risk analysis occur in multiple places. Final design, implementation, integration,
and test occur in iteration 4. The spiral can be repeated multiple times for multiple builds. Using
this method of development, some functionality can be delivered to the user faster than the
waterfall method. The spiral method also helps manage risk and uncertainty by allowing multiple
decision points and by explicitly admitting that all of anything cannot be known before the
subsequent activity starts.

Rapid prototype
The Rapid prototyping model is intended to provide a rapid implementation of high level
portions of both the software and the hardware . the approach allows developers to construct
working portion of hardware and software in incremental stages.Each stage through the
cycle,one incorporates a little more of the intended functionality.The prototype is useful for both
the designer and the customer. The prototype can be either evolutionary or throughway. It has
the advantage of having a working system early in development process.
Problem solving-five steps to design

The 5 steps to a successful design are

Requirement definition.
System specification
Functional design
Architectural design
Prototyping.

The design process

The design process comprises five distinct stages although it may vary for particular projects or
design disciplines. This information may be useful when working with a designer to understand
the processes involved. Before the project is started however, a vital question has to be asked:
―Why do you need a new identity, brochure or website etc?‖ This question is the key to
undertaking a successful project.

Identifying and formulating the requirement specification

Requirements analysis in systems engineering and software engineering, encompasses those

tasks that go into determining the needs or conditions to meet for a new or altered product, taking
account of the possibly conflicting requirements of the various stakeholders, analyzing,
documenting, validating and managing software or system requirements. Figure 4.4 shows the
interface between the customer and the design process.

Figure 4.4 The interface between the customer and the design process.
Requirements analysis is critical to the success of a systems or software project. The
requirements should be documented, actionable, measurable, testable, traceable, related to
identified business needs or opportunities, and defined to a level of detail sufficient for system
design.

Conceptually, requirements analysis includes three types of activities

Eliciting requirements: the task of identifying the various types of requirements from various
sources including project documentation, business process documentation, and stakeholder
interviews. This is sometimes also called requirements gathering.
Analyzing requirements: determining whether the stated requirements are clear, complete,
consistent and unambiguous, and resolving any apparent conflicts.
Recording requirements: Requirements may be documented in various forms, usually
including a summary list and may include natural-language documents, use cases, user
stories, or process specifications.

Characterizing the system

Requirements analysis can be a long and arduous process during which many delicate
psychological skills are involved. New systems change the environment and relationships
between people, so it is important to identify all the stakeholders, take into account all their
needs and ensure they understand the implications of the new systems. Analysts can employ
several techniques to elicit the requirements from the customer. These may include the
development of scenarios, the identification of use cases, the use of workplace observation
or ethnography, holding interviews, or focus groups and creating requirements
lists. Prototyping may be used to develop an example system that can be demonstrated to
stakeholders. Where necessary, the analyst will employ a combination of these methods to
establish the exact requirements of the stakeholders, so that a system that meets the business
needs is produced.

The specification of the external environment should contain the following for each entity:

Name and description of the entity.

For each I/O variable, the following information is available
 
The name of the signal.

The use of the signal as an i/p or o/p.

The nature of the signal as an event,data,state variable.

Responsibilities-activities.
Relationships.
Safety and reliability.

The system design specification

The System Design Specification (SDS) is a complete document that contains all of the
information needed to develop the system. Systems design is the process of defining the
architecture, components, modules, interfaces, and data for a system to satisfy
specified requirements. Systems design could be seen as the application of systems
theory to product development. There is some overlap with the disciplines of systems
analysis, systems architecture and systems engineering. System design specification serves as a
bridges between the customers and designers as shown in figure 4.5.

Figure 4.5: The Customer, the requirement, the design and the engineer

The requirement specifications provides a view from the outside of the system, design
specification provides a view from the inside looking out as well. Design specification has 2
masters:

It must specify the system‘s public interface from inside the system.
It must specify how the requirements defined for and by the public interface are to be met
by the initial functions of the system.
Five areas should be considered are:

Geographical constraints.
Characterization of and constraints on interface signals.
User interface requirements
Temporal constraints.
Electrical infrastructure consideration
Safety and reliability

System specification versus system requirements


Requirements give a description of something wanted or needed. They are a set of needed
properties.

Specification is a description of some entity that has or implements those properties.

A System Requirements Specification is a structured collection of information that embodies the

requirements of a system.

Requirements and specifications are very important components in the development of

any embedded system. Requirements analysis is the first step in the system design process,
where a user's requirements should be clarified and documented to generate the corresponding
specifications. While it is a common tendency for designers to be anxious about starting the
design and implementation, discussing requirements with the customer is vital in the
construction of safety-critical systems. For activities in this first stage has significant impact on
the downstream results in the system life cycle.

For example, errors developed during the requirements and specifications stage may lead
to errors in the design stage. When this error is discovered, the engineers must revisit the
requirements and specifications to fix the problem. This leads not only to more time wasted but
also the possibility of other requirements and specifications errors. Many accidents are traced to
requirements flaws, incomplete implementation of specifications, or wrong assumptions about
the requirements. While these problems may be acceptable in non-safety-critical systems, safety-
critical systems cannot tolerate errors due to requirements and specifications. Therefore, it is
necessary that the requirements are specified correctly to generate clear and accurate
specifications.

There is a distinct difference between requirements and specifications. A requirement is a

condition needed by a user to solve a problem or achieve an objective. A specification is a
document that specifies, in a complete, precise, verifiable manner, the requirements, design,
behavior, or other characteristics of a system, and often, the procedures for determining whether
these provisions have been satisfied. For example, a requirement for a car could be that the
maximum speed to be at least 120mph. The specification for this requirement would include
technical information about specific design aspects. Another term that is commonly seen in
books and papers is requirements specification which is a document that specifies the
requirements for a system or component. It includes functional requirements, performance
requirements, interface requirements, design requirements, and developement standards.

A specification is a precise description of the system that meets stated requirements. A

specification document should be

Complete
Consistent
Comprehensible
Traceable to the requirement
Unambiguous
Modifiable
Able to be written

Functional design

The functional design process maps the "what to do" of the Requirements Specification into the
"how to do it" of the design specifications. During this stage, the overall structure of the product
is defined from a functional viewpoint. The functional design describes the logical system flow,
data organization, system inputs and outputs, processing rules, and operational characteristics of
the product from the user's point of view. The functional design is not concerned with the
software or hardware that will support the operation of the product or the physical organization
of the data or the programs that will accept the input data, execute the processing rules, and
produce the required output.

Functional Design is a paradigm used to simplify the design of hardware and software devices
such as computer software and increasingly, 3D models. A functional design assures that each
modular part of a device has only one responsibility and performs that responsibility with the
minimum of side effects on other parts. Functionally designed modules tend to have low
coupling.

Architectural design

The major objective of the Architectural design activity is the allocation or mapping of the
different pieces of system functionality to the appropriate hardware anf software blocks. Work is
based on the detailed functional structure. The important constraints that must be considered
include items as

The geographical distribution.

Physical and user interfaces
System performance
specifications.
Timing constraints and dependability requirements
Power consumption
Legacy components and cost.

Hardware and software specification and design

For the software design, the following must be analyzed and decided.

Whether to use a real time kernel.

Whether several functions can be combined in order to reduce the number of software
tasks and if so, how?
A priority for each task.
An implementation technique for each intertask relationship.

The important criteria that we strive to optimize are

 Implementation cost
Development time and cost
Performance and dependability constraints
Power consumption
Size

Functional model versus architectural model

An appropriate model has to include elements both at the functional and architectural level to be
able to represent and evaluate hardware/software system.

Functional model

The functional model describes a system through a set of interacting functional elements. The
design proceeds at a high level without initial bias toward any specific implementation. We have
freedom to explore and to be creative. The functional models will interact using one of the
following 3 types of relations

The shared variable relation-which defines a data exchange without temporal

dependencies.
The synchronization relation- which specifies temporal dependency.
The message transfer by port- which implies a producer/consumer kind of relationship.

Architectural model

Tha architectural model describes the physical architecture of the system based on real
components such as microprocessor, arrayed logics, special purpose processors,analog and
digital components, and the many interconnections between them.

Prototyping

The prototype phase leads to an operational system prototype. A prototype implementation

includes

Detailed design
Debugging
 Validation
Testing

A prototype is an early sample or model built to test a concept or process or to act as a thing to
be replicated or learned from. It is a term used in a variety of contexts, including semantics,
design, electronics, and software programming. A prototype is designed to test and trial a new
design to enhance precision by system analysts and users. Prototyping serves to provide
specifications for a real, working system rather than a theoretical one.

In many fields, there is great uncertainty as to whether a new design will actually do what is
desired. New designs often have unexpected problems. A prototype is often used as part of the
product design process to allow engineers and designers the ability to explore design alternatives,
test theories and confirm performance prior to starting production of a new product. Engineers
use their experience to tailor the prototype according to the specific unknowns still present in the
intended design. For example, some prototypes are used to confirm and verify consumer interest
in a proposed design whereas other prototypes will attempt to verify the performance or
suitability of a specific design approach.

In general, an iterative series of prototypes will be designed, constructed and tested as the final
design emerges and is prepared for production. With rare exceptions, multiple iterations of
prototypes are used to progressively refine the design. A common strategy is to design, test,
evaluate and then modify the design based on analysis of the prototype.

In many product development organizations, prototyping specialists are employed - individuals

with specialized skills and training in general fabrication techniques that can help bridge between
theoretical designs and the fabrication of prototypes.

Other Considerations

The 2 additional complementary and concurrent activities that need to be considered are

Capitalization and reuse

Requirement and traceability management.

Capitalization and reuse

Capitalization

Capitalization and reuse are activities that are essential to the contemporary design
process. Proper and efficient exploitation of intellectual properties is very important
.intellectual properties are designs, often patented, that can be sold to another party to
develop and sell as their product.

Reuse

One of the main purpose of reuse is to help designers shorten the development life cycle.
Component reuse is facilitated in 2 ways: present and future.

To be reused, a component needs to be

Well defined
Properly modularized
In conformance to some interchange standard.

Requirement and traceability

management Requirement traceability

Requirement traceability refers to the ability to follow the life of a requirement in both the
forward and reverse directions through the entire design process and the design. The few
important pieces of informations are

The means for the project manager and the customer to moniter the development
progress.
A path that can be used during the verification and validation of the product against the
original specification.
A means of identifying which hardware or software modules are affected if a requirement
changes.

Requirement management

Requirement management addresses

 Requirement specifications
Changes
Improvements
Corrections

During the design, such changes are difficult to avoid for many reasons. Therefore a clear
procedure that facilitates a way to accommodate such modifications has to be used during the
whole design process.

Archiving the project

When the product has finally been released to production, some work remains to be done. If the
product follows the typical life cycle, bugs that must be fixed will be expected and added, and
the next generation product will build on the current. The typical project will have had many
contributors. A basic list can include

Product planning
Design and development
Test
Manufacturing
Marketing
Sales

Each group will have information, knowledge, documentation, and tools that will be important in
future. figure depicts a typical project software directory.