EC8791-EMBEDDED & REAL

TIME SYSTEMS
Topic - 1
B.MANIKANDAN
AP/ECE, UCE (BIT)
ANNA UNIVERSITY.
Success Criteria
 Definition of Embedded System
 Difference between general
purpose and dedicated purpose
computer.
 Characteristics of Embedded
computing
 Challenges of Embedded
ERTS- Module1 2
computing.
Embedded System Definition
o Combination of Hardware and Software
o to perform specific task(s)
o with real-time constraints and fault- tolerance.
o Real-time constraint - the system one which
processes input within the deadline to provide
output.
o Fault tolerance – Should not ACCEPT / should
intimate that its false input.

Example of Embedded systems

 ATM
 DTH
 DVD player
ERTS- Module1 3
 Difference between General purpose
computer and specific purpose
computer
General Purpose Computer Specific Purpose Computer
 Powerful resource Limited resource
 Voneuman Architecture Harvard Architecture
 User can program for any Only developer can
tasks program
 May not be real-time Specific tasks
 CPU will be Should adhere real-time
Microprocessor characteristics
CPU may be μp or μc

ERTS- Module1 4
 Complex systems and
Microprocessors
 Embedding Computers
 Characteristics of Embedded computing
 Why Microprocessor?
 Physics of software
 Challenges in Embedded computing
 Performance in Embedded Computing

ERTS- Module1 5
 Embedding Computers
Whirl wind- First Ever real-time
computing – late 1940- early
1950
Simple Calculator – Microwave
oven – Washing Machine
CPU starting from 4 bit – 32 bit
Microprocessors, 8 and 16 bit
Microcontrollers
In Automotive finds application
in late 1970s for Carburetor.
ABS and ASC-T

ERTS- Module1 6
 Characteristics of Embedded
Computing
• Complex Algorithm
• User Interface
• Real-time
• Multi-rate
• Manufacturing Cost
• Power and Energy

ERTS- Module1 7
 Why μp?
• Efficient way to implement digital design.
Execution speed – interpretation overhead – parallelism
• Easier to build product that can provide
various set of features.
Standing on the shoulder of giants- latest generation of
VLSI fabrication technology

ERTS- Module1 8
 Physics of Software
• Software performance and energy consumption are very
important properties when we are connecting our
embedded computers to the real-world. We need to
understand the sources of performance and power
consumption if we are to be able to design programs
that meet our application’s goals. we don’t have to
optimize our programs by pushing around electrons.
• In many cases, we can make very high-level decisions
about the structure of our programs to greatly improve
their real-time performance and power consumption. As
much as possible, we want to make computing
abstractions work for us as we work on the physics of
our software systems.
ERTS- Module1 9
Challenges in Embedded Computing

• Hardware needed
• Meeting Deadline
• Minimizing power consumption
• Upgradable design
• Reliability
– Complex Testing
– Limited observability & controllability
– Restricted Development environment

ERTS- Module1 10
 Performance in Embedded
Computing
• Deadline driven programming
– If output doesn’t meet the deadline, its erroneous
even the output is functionality wise correct.
Need to analyse the real-time behaviour with
different level of abstraction
1. CPU
2. Platform
3. Program
4. Task
5. Multiprocessor

ERTS- Module1 11
 End of Topic - 1
Outcome Criteria
 Definition of Embedded System
 Difference between general purpose and
dedicated purpose computer.
 Characteristics of Embedded computing
 Challenges of Embedded computing.

ERTS- Module1 12
Success Criteria
 Various Steps involved in Embedded system
design.
 Design Methodology
- Score card - To ensure that everything is
correctly.(Performance/ Performing functional test)
- Develop Computer aided tools – breaking the process into
manageable steps
- Members of the design to communicate

ERTS- Module1 13
Embedded System Design Process

• Top down Design

Requirements specification Architecture

System Components
Integration

ERTS- Module1 14
Embedded System Design Process

• Bottom up Design

Requirements specification Architecture

System Components
Integration

ERTS- Module1 15
 Requirements
• Gathering information from the customers
Envision user interaction with the systems.

• Customers need not be technical person

• Requirements can be classified into
functional and non functional
• Example of non functional requirements
System speed, Physical size and weight, Cost and power
consumption.

ERTS- Module1 16
 Specification
• More precise
• Contract between customer and
architecture
• Prepare carefully so as to meet customer
requirement
• Strange for amateur developer
• Should be understandable so that someone
can verify whether meets system
requirement and overall expectations of the
customer.

ERTS- Module1 17
 Architecture
• Describes how the system implements
function specified by requirement
• Plan for overall structure of the system
• Block diagram – shows major operation
and data flow
• H/w Block diagram S/w Block diagram.

ERTS- Module1 18
 Hardware and Software
Components
• Builds in conformance to the architecture
and specification.
• The components will in general include both
hardware and software modules.
• Some readymade and some need to design
• S/W module must use expertise – to ensure
system runs properly in real-time
• Should not occupy more memory space
than allowed

ERTS- Module1 19
 System Integration
• Not just plugging everything together
• Bugs found during system integration
• Building system in phases and running
proper test fixes the bugs easily
• System integration is difficult since it
uncovers problems.

ERTS- Module1 20
 End of Topic - 2
Outcome Criteria
 Design Methodology
 Various Steps involved in
Embedded system design.

ERTS- Module1 21
 Topic -3
• Success Criteria

 Case Studies – GPS Moving Map & Model

Train Controller
 Inculcate and impose design methodologies
learnt in the previous topic.

ERTS- Module1 22
Case Study – GPS moving Map
• Display of GPS moving map

ERTS- Module1 23
Requirement form - GPS Moving
map

ERTS- Module1 24
Architecture – GPS moving map

ERTS- Module1 25
 Model Train Controller
• System Setup

ERTS- Module1 26
Train Signaling

ERTS- Module1 27
Bit Encoding in DCC

ERTS- Module1 28
 Requirement

Base Line Packet

- Minimum Packet that must be accepted by all
DCC compliance models
- It has 3 bytes
- Address, Instruction and Error correction code

ERTS- Module1 29
 Packet Format

PSA(sD)+E
P – Preamble – Sequence of 10 “1” bits
S – Packet Start bit – Single bit “0”
A – Address byte- 8 bits
s – Data byte start bit – Single bit “0”
D – Data byte(s)
E – Packet end bit – Single bit – “1”

ERTS- Module1 30
 Conceptual Specification
• Model of train control system
– Command unit & Train Board Component

ERTS- Module1 31
Collaboration Diagram

ERTS- Module1 32
Class Diagram for model train
Controller

ERTS- Module1 33
Sequence Diagram to Tx a control
input

ERTS- Module1 34
State diagram - Formatter

ERTS- Module1 35
State Diagram – Panel

ERTS- Module1 36
 Topic -3
• Outcome Criteria

 Able to design – GPS Moving Map & Model

Train Controller
 Could able to Inculcate and impose design
methodologies for the process .

ERTS- Module1 37
 Design Methodologies
• embedded computing systems are too
complex to design by one person
• process is important
• Typical specification of the product includes
– Functionality, Manufacturing cost, Performance
and power consumption.
 Design process has three important goals
beyond function, Performance and Power
 Time to Market - First to market – Profitable market life
Design Cost – NRE – Bulk volume - cheaper
Quality - Correctness, reliability, and usability.

ERTS- Module1 38
 Design Flow
• Sequence of steps to follow during design
• Few design flow models are
– Water fall Model
– Spiral model
– Successive refinement
– Hardware/Software
– Hierarchical

ERTS- Module1 39
Water flow Model

ERTS- Module1 40
Spiral model

ERTS- Module1 41
Successive Refinement

ERTS- Module1 42
Simple Hardware/Software

ERTS- Module1 43
Hierarchical

ERTS- Module1 44
Concurrent Engineering –
Telephone system

ERTS- Module1 45
 Concurrent Engineering –
Telephone system – contd..,

ERTS- Module1 46
 Requirement Analysis
• Before designing a system need to know
what to design
• Goal is to communicate between the
customers and designers effectively
• Can be classified as
– Functional – What the system need to do
– Non Functional – Any attribute of the system

ERTS- Module1 47
 Characteristics of the requirement
form
• Correctness – Describes customer needs –avoid – over
requirement & unnecessary condition
• Unambiguousness – Should be of one plain language
interpretation & clear
• Completeness – All requirement should be included
• Verifiability – Cost effective way to ensure each requirement is
satisfied in the final product
• Consistency – one requirement should not contradict other
• Modifiability – Should be structured to meet the changing
requirement
• Traceability
» Traceable from requirement to reason why this
exists
» Trace forward how each requirement is satisfied in
implementation

ERTS- Module1 48
 Specification Analysis
• Control oriented Specification Analysis
– State machine specification language (SDL)
– Its an event oriented state machine model
– Has states, actions and both conditional and
un conditional transitions

ERTS- Module1 49
SDL Specification Language

ERTS- Module1 50
 State chart
• Well-known technique for state-based
specification that introduced some
important concepts.
• Its notation uses an event-driven model.
• It allow states to be grouped together to
show common functionality.
• There are two basic groupings:
OR and AND.
ERTS- Module1 51
OR State in State-chart

ERTS- Module1 52
AND state in State-chart

ERTS- Module1 53
Advanced Specification – TCAS-II

ERTS- Module1 54
Top Level Description of CAS

ERTS- Module1 55
CAS contd..,

ERTS- Module1 56
 System Analysis and Architecture
Design
• Way to get handle on the overall system
• CRC card methodology
• Suits well for Object Oriented design
• Acronym of CRC
– Classes
– Responsibilities
– Collaborator

ERTS- Module1 57
 Layout of CRC card

• Easy to get non computer people (Domain

Expert) to create this card

ERTS- Module1 58
 CRC Card – Analysis & Design
methodology
• Develop initial list of Classes
– Represents Architectural object
– Identify category the class fall into
• Write Responsibilities and collaborator for
initial list
• Create usage scenarios
• Walk through scenarios
• Refine the Classes, Responsibilities and
Collaborator
• Add Class relationship

ERTS- Module1 59
 System Analysis and Architecture
Design
• CRC card analysis for Elevator
• Basic set of classes:
• Real-world classes: elevator car, passenger, floor
control, car control, and car sensor.
• Architectural classes: car state, floor control reader,
car control reader, car control sender, and scheduler.
• Each class, we need initial set of responsibilities and
collaborators.
• (An asterisk, *, is used to remind ourselves which
classes represent real-world objects.)

ERTS- Module1 60
ERTS- Module1 61
• Several usage scenarios define the basic operation of
the elevator system as well as some unusual scenarios:
1. One passenger requests a car on a floor, gets in the car
when it arrives, requests another floor, and gets out
when the car reaches that floor.
2. One passenger requests a car on a floor, gets in the car
when it arrives, and requests the floor that the car is
currently on.
3.A second passenger requests a car while another
passenger is riding in the elevator.
4. Two people push floor buttons on different floors at the
same time.
5. Two people push car control buttons in different cars at
the same time.

ERTS- Module1 62
 Quality Assurance
• The quality of a product or service can be
judged by how well it satisfies it’s intended
function
• The quality assurance (QA) process is vital for
the delivery of a satisfactory system.
• Reasons for low quality
– Shoddily manufactured
– Improper component design
– Poorly conceived architecture
– Poor understanding of products requirement

ERTS- Module1 63
 Quality Assurance Techniques
• Process is crucial: Haphazard development leads to haphazard products
and low quality.
Knowing what steps are to be followed to create a high quality
product is essential to ensuring that all the necessary steps are in fact
followed.
• Documentation is important:
Documentation has several roles: The creation of the documents
describing processes helps those involved understand the processes;
documentation helps internal quality monitoring groups to ensure that the
required processes are actually being followed; and documentation also
helps outside groups (customers,auditors,etc.) understand the processes
and how they are being implemented.
• Communication is important: Quality ultimately relies on people. Good
documentation is an aid for helping people understand the total quality
process.
The people in the organization should understand not only their specific
tasks but also how their jobs can affect overall system quality.

ERTS- Module1 64
Capability Maturity Model(CMM)
• Well known way of measuring quality of an
organization(Software Development)process.
• It Defines five levels
– Initial -poorly organized process & few well defined process
– Repeatable – Provides tracking mechanism mgmt knows how
well the process is progressing
– Defined – Documented and standardized
– Managed – Detailed measurement of Development process
and product Quality
– Optimizing – Feedback from previous level & to take
measure for quality sustenance.

ERTS- Module1 65
Verifying the Specification

ERTS- Module1 66
 Design Reviews
• The design review is a simple, low-cost way to catch bugs early
in the design process.
• A design review is simply a meeting in which team members
discuss a design,
reviewing how a component of the system works.
• Some bugs are caught simply
by preparing for the meeting, as the designer is forced to think
through the
design in detail.
• Other bugs are caught by people attending the meeting, who will
notice problems that may not be caught by the unit’s designer.
• By catching bugs early and not allowing them to propagate into
the implementation, the time required to get a working system
may be reduced.
• We can also use the design review to improve the quality of the
implementation and make future changes easier to implement.

ERTS- Module1 67
Members of design review meeting
• Thedesigners - present their design to the rest
of the team for review and analysis.
• The review leader - coordinates the pre-meeting
activities, the design review itself, and the post-meeting
follow-up.
• The review scribe - records the minutes of the
meeting so that designers and others know which
problems need to be fixed.
• The review audience - studies the component.
Audience members will naturally include other members of the
project for which this component is being designed. Audience
members from other projects often add valuable perspective
and may notice problems that team members have missed.

ERTS- Module1 68
 System level performance analysis

• To get the data from memory to the CPU

read from the memory.
transfer over the bus to the cache; and
transfer from the cache to the CPU.

ERTS- Module1 69
 Contd..,
• Time required to transfer from the cache
to the CPU is included in the instruction
execution time.
• Most basic measure of performance is
bandwidth— the rate at which we can move data.
• Case study of image 320X240
• If that image is of video frame

ERTS- Module1 70
 t =TP
Where T= Bus cycle;
P = clock period;
Tb asi
c(
N ) = (D+ O
)
(N/
W
)
For Burst data
Tburs
t(N) = (BD+O
)
(
N
/W
)

ERTS- Module1 71
Memory Aspect ratio

ERTS- Module1 72
Consumer Electronics

ERTS- Module1 73
ERTS- Module1 74
ERTS- Module1 75
Low Level class diagram

ERTS- Module1 76
Mechanism class

ERTS- Module1 77
System Architecture

ERTS- Module1 78