Overview

• Embedded systems overview

– Millions of computing system are built

– Different systems for different purposes

– Embedded within large electronics devices

1
 Overview

• Computing systems are everywhere

• Most of us think of “desktop” computers
– PC’s
– Laptops
– Mainframes
– Servers
• But there’s another type of computing system
– Far more common...

2
Application Area of embedded systems

Embedded systems are found in variety of devices like

• Consumer Electronics: Cell phone, digital camera,

camcorders, videocassettes recorders, video games,
calculator.

• Home Appliances: microwave oven, answering

machine, home security system, washing machine,
coffee maker.

3
Application Area of embedded systems

Embedded systems are found in variety of devices like

• Office Automation: Fax machine, Copier, printer,

scanner.

• Business Equipments: cash reader, alarm system, card

reader, automated teller machine.

4
Some common characteristics of embedded
systems
• Single-functioned
– Executes a single program, repeatedly
• Tightly-constrained
– Low cost, low power, small size, fast computing
• Reactive and real-time
– Continually reacts to changes in the system’s
environment
– Must compute certain results in real-time without
delay
5
 An embedded system example -- a digital
camera
Digital camera chip
CCD

CCD preprocessor Pixel coprocessor D2A

A2D

lens

JPEG codec Microcontroller Multiplier/Accum

DMA controller Display ctrl

Memory controller ISA bus interface UART LCD ctrl

• Single-functioned -- always a digital camera

• Tightly-constrained -- Low cost, low power, small size, fast computing
• Reactive and real-time -- only to a small extent
6
 Design challenge – optimizing
design metrics
• Designer goal:
– Construct an implementation that fulfill desired
functionality, optimally

• Design metric is
– A measurable feature of a system’s implementation
– Optimizing design metrics is a key challenge

7
 Design challenge – optimizing
design metrics
• Common metrics
– Unit cost: the monetary cost of manufacturing each copy of the
system, excluding NRE cost
– NRE cost (Non-Recurring Engineering cost): The one-time
monetary cost of designing the system
– Size: the physical space required by the system
– Performance: the execution time or throughput of the system
– Power: the amount of power consumed by the system
– Flexibility: the ability to change the functionality of the system without
incurring heavy NRE cost

8
 Design challenge – optimizing design
metrics
• Common metrics (continued)
– Time-to-prototype: the time needed to build a working version of
the system

– Time-to-market: the time required to develop a system to the point

that it can be released and sold to customers

– Maintainability: the ability to modify the system after its initial release
– Correctness: Confidences that the designer has implemented
system’s functionality correctly.
– Safety: Probability that system will not cause harm.

9
 Design metric competition -- improving
one may worsen others
• To best meet the optimization
Power
challenges –

• The designer must have

expertise with both software
Performance Size and hardware
– A designer must be
comfortable with various
NRE cost
technologies & must be
able to migrate from one
technology to another.

10
 NRE and Unit cost - metrics
• Costs:
– NRE cost (Non-Recurring Engineering cost): The one-time
monetary cost of designing the system
– Unit cost: the monetary cost of manufacturing each copy of
the system, excluding NRE cost

total cost = NRE cost + unit cost * # of units

per-product cost = total cost / # of units
= (NRE cost / # of units) + unit cost

11
 NRE and Unit cost - metrics
• Example
– NRE=$2000, unit=$100
– For 10 units
– total cost = $2000 + 10*$100 = $3000
– per-product cost = $2000/10 + $100 = $300

Amortizing NRE cost over the units results in an additional $200 per unit

• Thus, the larger the volume, lower the per product cost.

• Hence the designer has to consider a revenue impact of both time-

to-market and per-product-cost and other relevant design metric,
when evaluating different technologies.

12
 The Performance Design - metric

• Clock frequency, instructions per second

– e.g., Digital camera – user cares about how fast it processes
images, not clock speed or instructions per second

• Latency (response time)

– Time between task starts and task ends
– e.g., Camera’s A process an image in 0.25 seconds
• Throughput
– Number of tasks per second,
– E.g Camera A processes 4 images per second

13
 Three key embedded system technologies

• Technology
– A manner of accomplishing a task, using technical
processes, methods, or knowledge

• Three key technologies for embedded systems

– Processor technology
– IC technology
– Design technology

14
Real Time Systems

15
 What is Real Time Systems

A system is called real-time:

Whenever we need to quantitatively express time to describe its

behavior.

How to describe the behavior of a system?

List inputs to the system and the corresponding system response

16
A Typical Real Time Systems

17
 Real Time Systems

• A Sensor converts some physical characteristics of its environment

into electrical signals

• A photo-voltaic cell converts light energy into electrical energy

• A temperature sensor operates based on the principle of a
thermocouple
• A pressure sensor operates based on the piezoelectricity
principle.

18
 Real Time Systems

• An Actuator converts electrical signals from computer into

physical actions

• A physical action may be

• Motion, changes of thermal, electrical, pneumatic or
physical characteristics of some objects.

• E.g., Motors, Heaters, Hydraulic and pneumatic actuators,

stepper motors

19
 Real Time Systems
• A Low cost Servos
• A servo is a small wireless device that has a shaft, the shaft
can be positioned at specific angular positions – by sending
a coded signal
• As long as a coded signal exists on the input line, the servo
will maintain the angular positions of the shaft
• As the coded signal changes, the angular position of the
shaft changes
• Servos are used in robots, radio controlled cars, puppets etc

20
 Basic Model of Real Time Systems

Input
Conditioning Input
Sensors Unit Interface
Real
Time
Computer
Output
Conditioning Output
Unit Interface
Actuators
Human
Computer
Interface

21
 Sample Applications
Traffic control system

Agile Manufacturing

22
 Sample Applications

Industrial Internet
and
Internet of Things

23
 Real Time Systems Introduction

In RTS’s the correctness of the system depends not

only on the logical result of computation, but also on
the time at which the results are produced.

• Hard real-time systems (e.g., Avionics, Industrial control

application, on-board computers).
• Firm real-time systems (e.g., Banking, Online transaction
processing, satellite based surveillance applications).
• Soft real-time systems (e.g., Video streaming, railway
reservation system, web browsing).

24
 Real Time Systems

•Hard deadline: penalty due to missing deadline is a higher order of

magnitude than the reward in meeting the deadline
•Firm deadline: penalty and reward are in the same order of
magnitude
•Soft deadline: penalty often lesser magnitude than reward

25
 Real Time Systems – Example Car Driver
• Mission: Reaching the destination safely.
• Controlled System: Car.
• Operating environment: Road conditions.

• Controlling System
- Human driver: Sensors - Eyes and Ears of the driver.
- Computer: Sensors - Cameras, Infrared receiver, Laser
telemeter, Navigation system, Street maps.

• Controls: Accelerator, Steering wheel, Break-pedal.

• Actuators: Wheels, Engines, and Brakes.

26
 Real Time Systems – Example Car Driver

• Critical tasks: Steering and breaking.

• Non-critical tasks: Turning on radio.

• Performance measures the goodness of the outcome relative

to the best outcome possible under a given circumstance.

• Cost of fulfilling the mission → Efficient solution.

• Reliability of the driver → Fault-tolerance is a must.

27
 Real Time Operating System

 What is a Real Time OS?

 An embedded system responds to external inputs:

 If response time to an event is too long, the system fails

 General purpose Operating Systems

 Not designed for real-time use

 Hence Real Time Operating Systems

 Help tasks meet their deadline

28
 Real Time Operating System

 How to specify deadline and how to meet task deadline?

 By proper task scheduling, task precedence constraints,

various tasks resource requirement etc

29
 Characteristics of ES
Real Time: Every real-time task is associated with some time
constraints e.g deadline

Correctness Criteria : Result should be logically correct and

within the stipulated time

Safety and Task Criticality: A critical task is one whose failure

causes system failure

- A safety system does not cause any damage

- A safety-critical real-time system is one where any failure
causes severe damage

30
 Characteristics of ES

Safety and Reliability

• Independent concept in traditional systems
-A safe system does not cause damage even when it fails
-A reliable system operates for long time without any fail
• A system can be safe and unreliable and vice versa
- A safe unreliable system - e.g, word processor
- An unsafe reliable system – gun

 An unreliable system can be made safe upon failure – by

reverting to fail-safe-state – e.g, traffic lights

31
 Real Time Systems

 Fail-Safe States helps separate the issue of safety and reliability

• i.e even if a system is unreliable, it can always be made to fail
in a fail-safe state

 For a Safety-Critical system (ES/RTS)

• No fail-safe-state exists
• e.g,. Navigation system in an aircraft

 for safety-critical system – the only way to achieve safety is by

making it reliable

32
 Characteristics of ES

Summary

 A safety-critical system is one for which a failure can cause

severe damage

 A safety-critical system does not have any fail-safe state

In ES, safety can be ensured only through increased reliability

33
 Real Time Tasks
• Periodic tasks

• Aperiodic tasks

• Sporadic Tasks

34
 Real Time Tasks
• Periodic tasks
- Time-driven. Characteristics are known a priori
- Task Ti is characterized by (ei, pi)
E.g.: Task monitoring temperature of a patient in an ICU.

• Aperiodic tasks
- Event-driven. Characteristics are not known a priori
- Task Ti is characterized by (ai, ri, ei, di)
E.g.: Task activated upon detecting change in patient’s condition.

• Sporadic Tasks
– Known minimum inter-arrival time among successive instances of a
(periodic) task, rather strictly being periodic.

pi : task period ai : arrival time ri : ready time

di : deadline ei : worst case execution time.
35
 Task Constraints
• Deadline constraint
• Resource constraints
– Shared access (read-read)
– Exclusive access (write-x)
• Precedence constraints
– T1  T2: Task T2 can start executing only after T1 finishes its
execution
• Fault-tolerant Requirements
– To achieve higher reliability for task execution
– Redundancy in execution
– h/w - BIST (built-in self-test), triple modular redundancy
– S/W – N-version programming, recovery blocks

36
 Common Misconceptions

• Real-time computing is equivalent to fast computing.

• Real-time programming is assembly coding, priority

interrupt programming, and device drivers.

• Real-time systems operate in a static environment.

• The problems in real-time system design have all been

solved in other areas of computer science.

37
 Real Time Systems - issues

• Resource Management (RM) Issues

– Scheduling, Fault-tolerance, Resource reclaiming, RT
Communication

• Architectural Issues
– Computing subsystem, Communication subsystem, I/O
subsystem

• Software Issues
– Requirements, specification, verification, Real-time
languages, Real-time databases

38
 Notion of Predictability

• The behavior of the RTS must be predictable means:

With certain assumptions about workload and failures, it should be

possible to show at “design time” that all the timing constraints of
the application will met.

• For static systems, 100% guarantees can be given at design time.

• For dynamic systems, 100% guarantee cannot be given since the
characteristics of tasks are not known a priori.

• In dynamic systems, predictability means, once a task is admitted

into the system, its guarantee should never be violated, as long as
the assumptions under which the task was admitted hold.

39
 Optimal scheduling -- definition

• A static scheduling algorithm is said to be optimal if, for any set

of tasks, it always produces a feasible schedule (i.e., a schedule
that satisfies the constraints of the tasks)

• A dynamic scheduling algorithm is said to be optimal if it always

produces a feasible schedule whenever a static algorithm with
complete prior knowledge of all the possible tasks can do so.

• Static scheduling is used for scheduling periodic tasks, whereas

• Dynamic scheduling is used to schedule both periodic and
aperiodic tasks.

40
 Preemptive vs Non-preemptive scheduling

• Preemptive Scheduling
– Task execution is preempted and resumed later
– Preemption occurs to execute higher priority task.
– Offers higher schedulability
– Involves higher scheduling overhead due to context
switching

• Non-preemptive Scheduling
– Once a task starts executing, it completes its full execution
– Offers lower schedulability
– Less overhead due to less context switching

41
 Architectural Issues

• Predictability in: Instruction execution time, Memory access,

Context switching, Interrupt handling.

• RT systems usually avoid caches and superscalar features.

• Support for error handling (self-checking circuitry, voters,

system monitors).

• Support for fast and reliable communication (routing, priority

handling, buffer and timer management).

42
 Architectural Issues

• Support for scheduling algorithms (fast pre-emptability,

priority queues).

• Support for RTOS (multiple contexts, memory management,

garbage collection, interrupt handling, clock synchronization).

• Support for RT language features (language constructs for

estimating worst-case execution time of tasks).

43
 Requirements…

• Functional requirements: Operation of the system and

their effects.

• Non-Functional requirements: e.g., timing constraints.

• F & NF requirements must be precisely defined and

together used to construct the specification of the system.

44
 Introduction: Summary
• RTS require logical correctness and timeliness.
• RTS consists of a controlling system, controlled system, and the
environment.
• RTS are classified as: hard, firm, and soft RTS.
• Workload (tasks) are periodic, aperiodic, sporadic.
• The notion of predictability is very important in RTS.
• Important issues include:
– scheduling, precedence constraints, resource reclaiming, fault-
tolerance, RT communication, architectural issues, system
specification and verification, programming languages, and RT
databases.
45