UNIT 4

EMBEDDED SYSTEM DESIGN AND DEVELOPMENT

Introduction
The goal of every designer should be to develop a quality product Design is the process of translating customer requirements into a working system In descriptive terms the quality of the product is reflected in its meeting all customer requirements ie Functional requirements Performance requirements Reliability requirements The systematic approach is reflected in defining the process for the development

DIFFERENCE BETWEEN A SIMPLE DESIGN AND EMBEDDED SYSTEM DESIGN

Process
Raw Material Finished Product

Problem definition

Hardware Development Software Development

Finished Product

MARKET TECHNOLOGY TRADE-OFF

Taking old technology into old markets is EASY Taking new technology into new markets is DIFFICULT
TECHNOLOGY
OLD NEW

OLD

MARKET

NEW

Considerations while design & Product development is based on (directly or indirectly) development

negotiated contract between company and customers. Failure with respect to development and delivery costs or schedules leads to loss of sales market share and creditability We should always consider Reliability, safety and quality of the product Lack of quality results in unnecessary costs of repairs and loss of customer confidence and sales. Robust implies that the system performs even if it is partially damaged or operated at the extreme conditions Documentation/instruction manual accompanied with the product must be clear and understandable. Post- sale support including service is equally important.

Lifecycle models
Product lifecycle: Steps that describe the journey from requirements state to application state. It is Purely a descriptive representation. Breaks the development process in to series of interrelated activities Each activity plays a role of transforming its input (specification) in to an output (a selected solution). A software lifecycle model is a standardised format for Planning, organising, and running a new development project.

Fundamentals of design
Find out what the customer wants. Think of a way to give them what they want. Prove what you have done by building and testing it. Use the product to solve the customers problem. Improvise on the product.

Types of lifecycle models

Hockey stick model Waterfall model V cycle model Spiral model Rapid prototype model

Hockey stick model

Fits in any phase of engineering. Reliability and safety are the major issues to be addressed while designing the ES. If X axis = time and Y axis = cost, we see that Longer we delay in addressing those issues the greater the cost will be.

Waterfall model
Specification

Implementatio n

Waterfall Model

11

Waterfall model
Sequential flow. Successive steps are linked in chained manner. Output from one phase is fed as input to the next phase. One phase is completed, documented and signed-off before the next phase begins. Advantages Each phase is well documented. Maintenance easier. Disadvantages If there is a mismatch between what the client wanted and was is built this will not be known till the product is delivered.

Requirement

System Test

Decompositi on

System Integration

System Specificati on

Performan ce Test

Preliminary Design

Integration Test

Detailed Design

Unit Test

Code

V cycle model
V-Model has evolved from waterfall Model. Each phase must be completed before the next phase begins.
Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape.

Testing/verification process is invoked at each stage. Requirements ----- System / Functional Testing

High Level Design ------ Integration Test

Detailed Design -------Unit Testing

Brings high quality into the development of our products.

Specification and design top-down model. Implementation and testing bottom-up model.

Spiral model
Proposed by Barry Boehm in 1988. Philosophy is to start small.explore the risksdevelop a plan to deal with the risks..commit to an approach for the next iteration. Advantages: Better than waterfall model and V cycle model. Provides for several opportunities for risk assessment and management. Involves greater degree of customer involvement. Disadvantages: Elaborate Difficult to manage.

Steps in each iteration of Spiral lifecycle model Determine objectives, 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

Rapid prototyping model

Rapid prototyping model

Key idea: Customers are non-technical and usually dont know what they want/can have. Intended to provide rapid implementation of both hardware and software segments. Rapid prototyping emphasises requirements analysis and validation, also called: customer oriented development. prototypes can be of 2 types: 1) evolutionary prototype 2) Throwaway prototype
A prototype of the product is build rapidly and shown to the client before the product is completely built. Advantages : Any mismatches between requirement and the product can be found early. Disadvantages : Sometimes the prototype ends up being the final product which results in quality, maintenance problems. Caution: The Prototype Should never turn into the final Product

Five steps to design Moving from General to Specific

Requirement definition---- {external System Specification------ implementation} Functional design----------- {internal Architectural design--------implementation} Prototyping------------------- {integration}

Finally leading to production.

Identifying the Requirements

Identifying the Requirements- user point of view

It is the interface between customer and designer. Choose a life cycle model.

capture the formal descriptions of the complete system from customers. document these needs as written definitions and descriptions.
Important to consider both the system to be designed and the environment in which it is to operate.

System

The initial focus should be on the world or environment in which system operates Next one follows with an increasingly detailed description of the role played by the system in that environment. Go on refining the requirements. Environment point:
specification for the containing environment, a description/ definition of the inputs and outputs to and from that environment How the system will be used. Who is the target audience.

Environment

System

System point:
Starts with high-level of abstraction (imagination/ conception). through progressive refinement one moves to lower levels of the abstraction and more detailed understanding and definition.

The environment
It is a heterogeneous collection of entities. All physical devices to which the system is interconnected Physical attributes that can effect the system. The environmental specification should contain the following for each entity.
Name & description of the entity. Responsibilities/activities. Relationships between entity & responsibilities. safety and reliability. identify all the hazards/ flaws. Identify any regulating agency.

The system
Define inputs and outputs.
Inputs to the system are outputs of the environment. Outputs from the system are inputs to the environment. Each I/O variable should have the following:
Name of the signal. Whether the signal is used a Input or Output. Nature of the signal- event/ data/ state variable etc. Validity of the signal. Structure/characteristics of the signal Technical constraints (if any) associated with the signal.

Responsibilities/ activities
Define the function performed by the system. Identify the effects of the environment on the system. How the system should be used. Make use of UML tools, Data and control flow diagrams, to indicate the activities of the system.

Safety and reliability:

Safety guidelines, rules and regulations to be followed. Potential risks, failures failure modes. Failure management strategy.

The system design specification

Describes HOW will be the design carried out. It acts as a bridge between Requirements specification & design process. It must specify the systems public interface from inside the system. It must specify how the requirements by the public interface are met by the internal functions of the system. It Must formalize the requirements specification in precise, unambiguous language. It should be sufficiently clear, robust and proofread so that the engineers developing the product can do so without any problem. It should have concrete data, specified with proper tolerances, and constraints to all the input and output signals. All the timing diagrams and their attributes should be specified. All operational and functional behaviors should be described in details

Quantifying the system

Necessary technical details are added to the requirements specifications so as to enable the engineer to accurately execute the actual design.
System inputs & outputs:
Name of the signal. Whether the signal is used a Input or Output. Nature of the signalevent/ data/ state variable etc. Complete specification of the signal like nominal value, range, tolerances, timing etc Interrelationships with other signals including their mapping and execution constraints.

Quantifying the system

Responsibilities/ activities
Functional and operational specifications that quantify the dynamic behavior of the system. Define the functions to be performed by the system. Define the manner in which the function should operate. Range, tolerances & constraints of the Variables in the functions . Must contain event tables, equations, algorithms, pseudo code, flow diagrams, detailed UML diagrams, state charts, timing diagrams, sequence diagrams etc..

Quantifying the system

Technological specifications
User interface requirements
Accordance to standards like ISO

Electrical infrastructure considerations

Power supplies Power consumption/ dissipation Power management schemes Tolerances related to power supplies.

Temporal constraints
Internal/ external system delays Propagation delays

Constraints of Interfacing signals

Electrical/ optical/ wireless signals Range/ frequency / phase of the signals. Channel capacity / data rate etc..

Geographical constraints
Single room/ factory/ Network topologies( LAN/ MAN/ WAN/ WWW) Limited/ unlimited access (firewall) Cost of installation

Quantifying the system

Safety and reliability
Requirements for diagnostic tests, remote maintenance and upgrade. Consideration of system performance under partial/ full failure. Concrete numbers for MTTF & MTBF of any built-in circuitry / system.. MTTF (Mean Time To Failure) the component/ instrument will be replaced following a failure. MTBF (Mean Time Between Failures) the component/ instrument will be repaired following a failure

Problem statement
Consider yourself as a senior development engineer in some MNC. Suppose a new project is assigned to you by some client in which a counter has to be designed that can be used in avionics. They also specify that the budget is moderate. They should be able to employ the same counter on several other segments also. These counters should have the capability to operate remotely from a PC (in future) in order to reduce manpower. The main job of the counter is to track the no. of navigation radios coming down the production line per hour. Each radio arrival breaks the IR beam, which generates a 1 microsecond wide negative going 5 V pulse (on the newer lines) Each radio arrival breaks the IR beam, which generates a 1 microsecond wide positive going 5 V pulse (on the older lines) Frequency measuring range is from 100 Hz- 50 KHz -150MHz with 0.001 Hz resolution. There are 3 production lines that can measure
time duration 1 ms with 0.0001sec resolution. time duration 10 ms with 0.001sec resolution. time duration 1s with 0.001sec resolution.

Formulating the requirements Specification

Navigation Radio

Factory

Counter

User

Navigation Radio Measurement Sys

User

Counter

Remote Computer

Factory

Test Line

Nav Radio

Requirements specifications for a digital counter

Environment contains:
Set of navigation radios to be tested. User who is doing the testing. The factory. Industrial environment. Commercial grade temperature. Average lighting (halogen) rise in temp Line power/ battery operated. Manual operated Later to be remotely accessed remote connection to be made (dial-up/ wireless).

System description
User interface of the counter should have provision to measure the following: POWER ON/ OFF RESET Frequency of the signal time period of the signal Time interval between 2 events Range of the signal (low/ mid/ high) occurrence of events (slow/ fast) Triggering edge (rising/ falling) LCD/ Seven segment 6 digit display

 System inputs
Voltage range

System input and output specification

System outputs
Events occurrence rate
0- 99 per minute DC signals 0.0V to 4.5 V

Events occurrence rate

200 per minute (fast) 2000 per hour (slow)

time interval
High resolution = 1 ms Mid resolution = 10 ms Low resolution = 1 s (excluding resolution)

Time Period
High resolution = 1 ms Mid resolution = 10 ms Low resolution = 1 s

Time Period
High resolution = 2 ms Mid resolution = 20 ms Low resolution = 2 s (excluding resolution)

time interval
High resolution = 1 ms Mid resolution = 10 ms Low resolution = 1 s

Frequency range
High range = 200 MHz Mid range = 200 KHz Low range = 200 Hz. (excluding resolution)

Frequency range
High range = 150 MHz Mid range = 50 KHz Low range = 100 Hz.

 Measure frequency
Select Frequency mode If the frequency exceeds the max. limit, display shows full scale reading and flashes. If the frequency is below the min. limit, display shows 0 reading. Range of the frequency can be changed by the range select button. The user may start/ stop measuring the frequency by pressing the start trigger edge/ stop trigger edge button to select positive/negative edge triggering.

Measure period
Select period mode If the period exceeds the max. limit, display shows full scale reading and flashes. If the period is below the min. limit, display shows 0 reading. Range of the period can be changed by the range select button. The user may start/ stop measuring the period by pressing the start trigger edge/ stop trigger edge button to select positive/negative edge triggering.

Measure interval
Select interval mode. If the period exceeds the max. limit, display shows full scale reading and flashes. If the period is below the min. limit, display shows 0 reading. Range of the period can be changed by the range select button. The user may start/ stop measuring the interval by pressing the start trigger edge/ stop trigger edge button to select positive/negative edge triggering

Measure events
Select events mode. Range of the counting of events can be changed by the range select button. If the no. of counts exceeds the max. limit, display shows full scale reading and flashes. The user may start/ stop incrementing the count by pressing the start trigger edge/ stop trigger edge button to select positive/negative edge triggering The accumulated count will be reset to 0 at the end of counting.

System functional specification

Operating specifications
The system should operate in a standard commercial/ industrial environment
Temperature range 0-85C Humidity upto 90% Power AC 230V ,50 Hz with 10 % tolerance, 5V DC@10 mA,15V DC@500 mA system shall operate for min 8 hrs on a fully charged battery. Net weight of the counter: 2.75 kgs Dimensions: 90mm x 200mm x 300 mm MTBF min. of 10000 hrs The counter shall comply with the standards like IEC-1010, CSA-1010.1, UL-3111.1, CISPR-11

System requirements
Describes WHAT a system must do. Describes HOW WELL it has to do. Set of needed properties. Come from the mktg/sales deptt. indirectly customer representation Not concerned with the internal organization of the system. Informal, random language.

system specifications
Describes HOW the system must implement the requirements. It translates the description of needs to a more formal structure & model. Hardware/ software detailing with the respective constraints,& tolerances. Needs regular quantification of the state variables. Defines the internal organization of the system. Formal, complete, consistent, unambiguous, modifiable language.

Partitioning and decomposing a system

Modularity & encapsulation is mandatory.
Reuse. Less memory accesses Increase performance. Avoids thrashing. Reduce cache misses. Simplifies subcontracting security issues. Ensures a safe & robust design. Troubleshooting is easier. Easy to maintain and enhance the design. Helps meeting the economic goals of the design.

How to do partitioning??
Capture the behavior at high level. Map the functionality to the hardware & software. Each module should solve one well-defined piece of problem. Functionalities of various modules should not be mixed. Functionalities should be easily understandable. Ensure that Connections between the modules are independent. Try to keep like things together thereby reducing errors. Aim is to develop loosely coupled, highly cohesive modules

Coupling
Indicates how interdependent the modules are. Main objective is to make modules as independent as possible. (loosely coupled) Care should be taken at the time of partitioning to lower the coupling. Tightly coupled modules utilize shared data or interchange control information. therefore:
Debugging becomes difficult. Troubleshooting becomes difficult. Modifying becomes difficult. Maintaining becomes difficult.

How to reduce coupling??

Eliminate all unnecessary interaction between the modules. Minimize the amount of essential interaction between the modules. (reduce the no. of interconnections) Avoid using shared global variables. Instead pass variables in the parameter list/ sensitivity list of each module.

Cohesion
Opposite of coupling. Measure of strength of the functional interdependence of the elements in the modules of a system. Objective is to create highly cohesive modules whose elements are tightly related to each other. Types of cohesion:
Functional cohesion all elements contribute to execution of a single task. Sequential cohesion all elements are involved in one of the steps of the sequence. Communicational cohesion all elements work on procedures involving the same input data like image processing task. Temporal cohesion elements contribute to a no. of unrelated procedures that ordered sequentially. Logical cohesion elements contribute to procedures that are possible alternative methods of doing the same task. Procedural cohesion elements contribute to procedures that are not linked to each other.

Functional design
Formulate an appropriate internal functional architecture for the system. It formalizes the intended behavior of the system. Should be written by the engineer who develops the hardware/ software of the system. Should be easy to read and understand. First functional decomposition is done on the basis of essential internal variables & events. Go on refining the functions till leaf functions are obtained functional model of the system. It gives an estimate of the expected performance of the system ( internal behavior of the system.) It is written by using design tools like UML,Verilog etc.. Analyse & identify the signals flowing between the user & system. Analyse & identify the signals flowing within the various functional blocks of the system.

Hierarchical decomposition of the counter

Counter- environment interface

Functional partition of the counter

Architectural design
Mapping each functional module onto the appropriate physical hardware/ software blocks. It should be done keeping in mind the future enhancements/add-ons. Constraints imposed by technology/hardware/software are taken into consideration in deciding which portions of the system should be implemented in hardware or software. Types of constraints that have to be optimized:
Geographical distribution. Timing constraints development time & cost. Power consumption Implementation Cost involved. Performance & dependability constraints etc

Hardware architecture of the counter

Functional model
Located between system specifications and architectural model. Represents a system through a set of interacting functional elements. High level design model. Coarse-grain partitioning of the system. Freedom to explore & be creative.

architectural model
Located between functional model and prototype. Represents a system through its physical components like microprocessors, PLDs, ADC, DAC, buses etc. Fine -grain partitioning of the system. Refined form of the functional model.

prototyping
Tool for Confirming the system design. Its a proof of the concept/ idea. Launching a trial model. Hardware & software implementations are developed simultaneously by experts thereby reducing implementation time. It is a bottom-up process. i.e it must be checked for compliance with the specifications at each level in the top-down design. A prototype implementation includes:
Detailed design Debugging Validation Testing

Analysing the system design-check list

Verify that the solution is: meets the original requirements & specifications. Reliable Well documented instruction manual etc.. Easy maintenance Robust Safe Cost effective Modifiable

Static analysis
Complexity
Behavioral complexity
Less no of inputs & outputs. Minimal no of state variables. Minimize the description through words.

Dynamic analysis
Behavior verification
System Environment Boundary conditions

Functional complexity:
Less no of functions less no of interconnections

Performance analysis
Specific values of input & outputs for:
System environment

Cohesiveness
Measure of functional homogeneity of elements that comprise the modules. tight

Trade-off analysis

Coupling
Measure of interrelationships between modules. Loose

Other considerations
Capitalization
Proper & efficient exploitation of Intellectual Properties (IPs) patents that can be sold to another party to develop & sell as a part of their product.

Reuse
Helps the designers shorten the development life cycle. The component should have support any modification in the present as well as future scenarios. To be reused the component needs to be
Well defined Properly modularized In accordance to some interchange standard

Requirements traceability
Ability to follow the life of a requirement in both forward & reverse directions throughout the design process. Identifies which h/w or s/w modules are affected if a requirement changes.

Requirements management
Requirements modifications Changes Improvements Corrections

Archiving the project

What to save??
Important design information Project directories & their contents. Source code CAD drawings/ layouts of the component. Storage media (hard/ soft copies.) Tools/ s/w used with versions. Cost involved /bills/ invoices/warranty cards etc. For future revisions Addition of features Have a track of the vendors/ clients Mktg/ sale reports Post sale documentation.

Why to save??