Implementation Strategies for

Complex Embedded Systems

CPE112: Embedded Systems
Embedded System Design and Development

❑ 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.
Common Life Cycle Models

❑ Waterfall model
❑ V cycle model
❑ Spiral
❑ Rapid prototype
Waterfall model
❑ 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 Requirements, Design,
Development, Testing, Deployment, and Maintenance.
Waterfall 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.
Steps in Waterfall Method
1. Specification
2. Preliminary design
3. Detailed design
4. Implementation
Phases
1. Requirement: In this phase, we gather necessary information (types of
characteristics client wants) which will be used for development of the
project. It also defines system requirement specification. This phase
defines what to do.
2. Design: In design phase, we construct a design to implement the
requirements gathered in requirement phase. This phase defines how to
implement the system.
3. Coding/Development: Based on design phase, we then write actual code
to implement algorithms. The code/program should be efficient.
Phases
4. Testing: This phase is used to test the coding part. It checks all the
validation (work for each and every possibilities of input). If any bug
occurs, we report the bug to the design phase or development phase.
5. Maintenance: In this phase, we need keep updating information.

Image from: https://www.javatpoint.com/jira-waterfall-model

Waterfall model
❑ Deployment process contains software preparation and transition
activities such as
▪ conception and creation of the maintenance plan
▪ preparation for handling problems identified during development
▪ follow-up on product configuration management
❑ Problem and modification analysis process, 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. Finally, obtain all the required authorizations
to apply the modifications.
❑ The process of considering the implementation is a modification itself.
Waterfall model
4. Process acceptance of the modification: Confirming the modified
work with the individual (who submitted the request), to make sure
the modification provided a solution.
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, migration 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.
V model
❑ a graphical representation of the systems development lifecycle
❑ summarizes the main steps to be taken in conjunction with
the corresponding deliverables within computerized system
validation framework
❑ 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.
V model
❑ The V represents the sequence of steps in a project life cycle 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.
▪ 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.
V life cycle model
❑ Requirement
system/Functional Testing
❑ High level design
Integration testing
❑ Detailed design Unit testing

❑ Each test phase is identified with

its matching development phase
Spiral Model
❑ 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).
❑ combines the features of the prototyping and the
waterfall model
❑ intended for large, expensive and complicated
projects

Spiral Life Cycle Model Steps

Steps in Spiral Model Life Cycle
❑ 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
Spiral Model
❑ combines the idea of iterative development (prototyping) with the systematic,
controlled aspects of the waterfall model
❑ allows for incremental releases of the product, or incremental refinement
around the spiral
❑ 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.
❑ is based on continuous refinement of key products for requirements definition
and analysis, system and software design, and implementation (the code).
Spiral 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.
❑ 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.
Rapid Application Development (RAD)
❑ is intended to provide a rapid implementation of high level portions
of both the software and the hardware.
❑ allows developers to construct working portion of hardware and
software in incremental stages.
❑ Each stage through the cycle, 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.
5 Steps to a Successful Design
❑ Analysis and Quick Design
❑ User Design
❑ Testing
❑ Implementation

Image from: https://nix-united.com/blog/the-ultimate-guide-to-rapid-

application-development/
 Identifying and Formulating the
Requirement Specification
❑ Requirements analysis, 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.

The interface between the customer and the design process

 Identifying and Formulating the
Requirement Specification
❑ Requirements analysis is critical to the success of a systems or software project
▪ 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/ requirements gathering : identifying the various
types of requirements from various sources including project documentation,
business process documentation, and stakeholder interviews.
▪ 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, 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.
❑ 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.
▪ 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.
Characterizing the System
❑ 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 input/process or output/process.
▪ The nature of the signal as an event, data, state variable.
▪ Responsibilities-activities
▪ Relationships
▪ Safety and reliability
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.
▪ the application of systems theory to product development
❑ System design specification serves as a bridges between the customers and designers.

The Customer, the requirement, the design and the engineer

System Design Specification (SDS)
❑ 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.
Six 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 vs. System Requirements

❑ Requirements give a description of something wanted or needed.

They are a set of needed properties.
▪ 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.
▪ 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.
System Specification vs. System Requirements

❑ Specification is a description of some entity that has or implements

those properties.
▪ is a structured collection of information that embodies the requirements of a
system
▪ 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
Specification
❑ 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
❑ maps the "what to do" of the Requirements into the "how to do it" of the
design specifications.
❑ 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
▪ is a paradigm used to simplify the design of hardware and software devices such as
computer software and increasingly, 3D models
▪ 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
❑ is the allocation or mapping of the different pieces of system functionality
to the appropriate hardware and software blocks. Work is based on the
detailed functional structure.
❑ The important constraints that must be considered include items as:
▪ 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.
Hardware and Software Specification and Design

❑ The important criteria that we strive to optimize are:

▪ Implementation cost
▪ Development time and cost
▪ Performance and dependability constraints
▪ Power consumption
▪ Size
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.
❑ The functional models will interact using one of the following 3 types of
relations
▪ Shared variable relation: defines a data exchange without temporal
dependencies
▪ Synchronization relation: specifies temporal dependency
▪ Message transfer by port: implies a producer/consumer kind of
relationship
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
Prototyping
❑ 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.
▪ used in a variety of contexts, including semantics, design, electronics, and software programming
▪ is designed to test and trial a new design to enhance precision by system analysts and users
▪ 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
❑ Prototyping serves to provide specifications for a real, working system rather than a
theoretical one.
❑ 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.
Prototyping
❑ 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
▪ 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
❑ help designers shorten the development life cycle.
▪ To be reused, a component needs to be:
▪ Well defined
▪ Properly modularized
▪ In conformance to some interchange standard
Requirement and Traceability
Management
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 information are:
▪ means for the project manager and the customer to monitor the
development progress
▪ A path that can be used during the verification and validation of the
product against the original specification.
▪ 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
❑ 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.
Thank you for listening.
Reference
❑ https://www.bharathuniv.ac.in/colleges1/downloads/courseware_e
ce/notes/BEI605-%20Embedded-System.pdf