Transcript Real-Time embedded Systems

System Software
for Embedded Systems
Krithi Ramamritham
Kavi Arya
IIT Bombay
VLSI 2004
© Krithi Ramamritham / Kavi Arya
1
Embedded Systems?
© Krithi Ramamritham / Kavi Arya
2
Plan
• Embedded Systems
– Introduction
– Application Examples
• New Approaches to building ESW
–
–
–
–
New paradigms: Lava, Handel-C
Examples + “Engineering Returns to Software”
Build a RISC processor in 48hrs
Advantages of reconfigurable hardware.
• Real-time support for ESW
© Krithi Ramamritham / Kavi Arya
3
Embedded Systems
• Single functional e.g. pager, mobile phone
• Tightly constrained
– cost, size, performance, power, etc.
• Reactive & real-time
– e.g. car’s cruise controller
– delay in computation => failure of system
© Krithi Ramamritham / Kavi Arya
4
Hardware is not the whole System !!!
A Micro-Electronic System is the result of a projection of
…
– Architecture
– Hardware
– Software
… distinguished by its gross Functional Behaviour !
• Software is an important part of the Product and must
be part of the Design Process
… or we are only designing a Component of the
system.
© Krithi Ramamritham / Kavi Arya
5
Why Is Embedded Software Not
Just
Software On Small Computers?
• Embedded = Dedicated
• Interaction with physical processes
– sensors, actuators, processes
• Critical properties are not all functional
– real-time, fault recovery, power, security, robustness
• Heterogeneity
– hardware/software tradeoffs, mixed architectures
• Concurrency
Source:
Edward A. Lee, UC Berkeley
– interaction with multiple processes
SRC/ETAB Summer Study 2001
• Reactivity
– operating at the speed of the environment
 These features look more like hardware!
© Krithi Ramamritham / Kavi Arya
6
What is Embedded SW?
One definition:
“Software that is directly in contact with, or
significantly affected by, the hardware that it
executes on, or can directly influence the
behavior of that hardware.”
© Krithi Ramamritham / Kavi Arya
7
What is Embedded SW?
• What is it not?
• Application software can be recompiled and
executed on any number of hardware platforms so
long as the basic services/libraries are provided.
– It is divided by vertical market segments (application
domains)
– Well-established methodologies, architectures,…
– HW platform independent, highly portable
• Any SW that has no direct relationship with HW.
© Krithi Ramamritham / Kavi Arya
8
Embedded System Challenges for HW
Folks
• PARADIGM CHANGE!
– Designers main tasks convert from processor integration to
performance analysis. Concentration on functional
requirements instead of integration work
– Concentration on architectural exploration (including
performance analysis
 Re-use and Platform-based design become key!
 Early validation of system/solution correctness
 Parallel hardware and software development
 More effective use of previous work
 Faster ways to build new elements of a solution
 Ways to test more effectively, efficiently, quickly
© Krithi Ramamritham / Kavi Arya
9
Software Guys can Learn
from Hardware Experts!
• Concurrency
– the synchrony abstraction
– event-driven modeling
• Reusability
– cell libraries
– interface definition
• Reliability
– leveraging limited abstractions
Source:
Edward A. Lee, UC Berkeley
– leveraging verification
SRC/ETAB Summer Study 2001
• Heterogeneity
– mixing synchronous and asynchronous designs
– resource management
©
Krithi Ramamritham / Kavi Arya
10
Trade-offs. Methodology
ESW Architectural specifics
• Portability
– ESW itself is intended to provide portability for higher SW layers
– (At least parts of) ESW is per definition not portable
• Real-time
– Restricted use of standardized Inter-process communication
(IPC) mechanisms (CORBA,…) for performance reasons
– Typically hard real-time requirements
• RTOS dependency
– Implementation of OS like services
– Sometimes shielding of the RTOS to higher level SW layers
– Direct dependency on RTOS implementation
© Krithi Ramamritham / Kavi Arya
11
Functional Design & Mapping
F2
F1
F5
Functional
Design
Source:
Ian Phillips, ARM
F4
F3
VSIA 2001
Architectural
Design
HW1
Threa
d
(F2)
(F5)
(F3)
(F4)
HW2
HW3
HW4
RTOS/Drivers
Hardware Interface
© Krithi Ramamritham / Kavi Arya
12
The Embedded Market: Disruptive Change
Source: Jim Ready
President / CEO
MontaVista Software
Traditional
Embedded World
Never small enough
Never fast enough
Headless/Character-based
Standalone
Boot & Run from ROM
More Hardware than Software
Low-Level Programming Model
Application tied to hardware
© Krithi Ramamritham / Kavi Arya
Today’s
Embedded World
Never functional enough
Always connected
High Integration Chips (ASIC/SOC)
Architectural diversity
COTS & custom hardware
EPROM/Flash/Rotating Media
Software Intensive
Web interfaces
OOP Programming Model
Standard applications
• Time to Market Pressures
• Shortage of Embed. SW Engineers
13
Plan
• Embedded Systems
• New Approaches to building ESW
–
–
–
–
New paradigms: Lava, Handel-C
Examples + “Engineering Returns to Software”
Build a RISC processor in 48hrs
Advantages of reconfigurable hardware.
• Real-time support for ESW
© Krithi Ramamritham / Kavi Arya
14
Motorola Software Survey Findings
• Hardware design is a software task: IC designers write code (VHDL,
Verilog, Scripting)!
• We must become a software-intensive embedded system solutions
company, focused on integrating our platforms into users’
products in the future we’ll be neither a hardware nor a software company
– Focus on developing systems capability, not just a software counterpart to our
current hardware capability (though that’s needed too)
– We should have software content from drivers to applications
• The fundamental goal isn’t 70% margin on software products, it’s
helping someone choose your total solution
– Embedded systems platforms and solutions will be the key to market differentiation
and profitable growth
Source:
Bob Altizer, BASYS
VSIA 2001
© Krithi Ramamritham / Kavi Arya
15
Common Design Metrics
•
•
•
•
•
NRE (Non-recurring engineering) cost
Unit cost
Size (bytes, gates)
Performance (execution time)
Power (more power=> more heat & less
battery time)
• Flexibility (ability to change functionality)
© Krithi Ramamritham / Kavi Arya
16
Common Design Metrics
•
•
•
•
•
Time to prototype
Time to market
Maintainability
Correctness
Safety (probability that system won’t
cause harm)
© Krithi Ramamritham / Kavi Arya
17
Time to Market Design Metric
• Simplified revenue model
Revenues ($)
Peak revenue
Peak revenue from
delayed entry
On-time
Market
fall
Market
rise
Delayed
D
On-time
entry
W
Delayed
entry
2W
Time
– Product life = 2W, peak at W
– Time of market entry defines a triangle,
representing market penetration
– Triangle area equals revenue
• Loss
– The difference between the on-time and
delayed triangle areas
• Avg. time to market today = 8 mth
• 1 day delay may amount to $Ms
– see Sony Playstation vs XBox
Source: Embedded System Design:
Frank Vahid/ Tony Vargis (John Wiley
& Sons, Inc.2002)
© Krithi Ramamritham / Kavi Arya
18
NRE and unit cost metrics
• Compare technologies by costs -- best depends on quantity
– Technology A: NRE=$2,000, unit=$100
– Technology B: NRE=$30,000, unit=$30
– Technology C: NRE=$100,000, unit=$2
$200,000
$200
A
B
C
$120,000
$80,000
$40,000
A
B
$160
p er p rod uc t c ost
$160,000
tota l c ost (x1000)
Source: Embedded System Design:
Frank Vahid/ Tony Vargis (John
Wiley & Sons, Inc.2002)
C
$120
$80
$40
$0
$0
0
800
1600
2400
0
Numb er of units (volume)
800
1600
2400
Numb er of units (volume)
• But, must also consider time-to-market
© Krithi Ramamritham / Kavi Arya
19
Losses due to delayed market
entry
•
– On-time = 1/2 * 2W * W
– Delayed = 1/2 * (W-D+W)*(W-D)
Revenues ($)
Peak revenue
Peak revenue from
delayed entry
On-time
Market
fall
Market
rise
Delayed
D
On-time
entry
W
Delayed
entry
2W
Time
Source: Embedded System Design:
Frank Vahid/ Tony Vargis (John Wiley &
Sons, Inc.2002)
© Krithi Ramamritham / Kavi Arya
Area = 1/2 * base * height
•
•
Percentage revenue loss = (D(3WD)/2W2)*100%
Try some examples
– Lifetime 2W=52 wks, delay D=4
wks
– (4*(3*26 –4)/2*26^2) = 22%
– Lifetime 2W=52 wks, delay D=10
wks
– (10*(3*26 –10)/2*26^2) = 50%
– Delays are costly!
20
• Moore’s Law
Trends
– IC transistor capacity doubles every 18 mths
– 1981: leading edge chip had 10k transistors
– 2002: leading edge chip has 150M transistors
• Designer productivity has improved due to better
tools:
–
–
–
–
–
–
–
Compilation/Synthesis tools
Libraries/IP
Test/verification tools
Standards
Languages and frameworks (Handel-C, Lava, Esterel, …)
1981: designer produced 100 transistors per month
2002 designer produces 5000 transistors per month
© Krithi Ramamritham / Kavi Arya
21
Our New Understanding
• We have simultaneous optimisations of competing
design metrics: speed, size, power, complexity, etc.
• We need a “Renaissance Engineer”
– with holistic view of design process and comfortable with
technologies ranging from hardware, software to formal methods
• Maturation of behavioral synthesis tools and other
tools has enabled this kind of unified view of hardware/
software co-design.
• Design efforts now focus at higher levels of abstraction
=> abstract specifications now refined into programs
and then into gates and logic.
• There is no fundamental difference of between what
hardware and software can implement.
©
Krithi Ramamritham / Kavi Arya
22
Designer Productivity
• “The Mythical Man Month” by Frederick Brooks ’75
• More designers on team => lower productivity because
of increasing communication costs between groups
• Consider 1M transistor project:
- Say, a designer has productivity of 5000 transistor/mth
- Each extra designer => decrease of 100 transistor/mth
productivity in group due to comm. costs
– 1 designer
1M/5000 =
200mth
– 10 designer
1M/(10*4100) =
24.3mth
– 25 designer
1M/(25*2600) =
15.3mth
– 27 designer
1M/(27*2400) =
15.4mth
Source: Embedded
System Design: Frank
Vahid/ Tony Vargis (John
Wiley & Sons, Inc.2002)
• Need new design technology to shrink the design gap
© Krithi Ramamritham / Kavi Arya
23
Design Productivity Gap
• Designer productivity has grown over the last decade
• Rate of improvement has not kept pace with the chipcapacity growth
• 1981: leading edge chip:
– 100 designers * 100 trans/mth => 10k trans complexity
• 2002: leading edge chip:
– 30k designer mth * 5k trans/mth => 150M trans complexity
• Designers at avg. of $10k pm
=> cost of building leading edge chips gone from $1M in
1981 to $300M in 2002
• Need paradigm shift to cope with the complexities of
system design
© Krithi Ramamritham / Kavi Arya
24
Plan
• Embedded Systems
– Introduction
– Application Examples
• New Approaches to building ESW
–
–
–
–
New paradigms: Lava, Handel-C
Examples + “Engineering Returns to Software”
Build a RISC processor in 48hrs
Advantages of reconfigurable hardware.
• Real-time support for ESW
© Krithi Ramamritham / Kavi Arya
25
Embedded Applications
They are everywhere!
•
•
•
•
•
•
wristwatches, washing machines,
microwave ovens,
elevators, mobile telephones,
printers, FAX machines,
telephone exchanges,
automobiles, aircrafts
© Krithi Ramamritham / Kavi Arya
26
Embedded Apps
• A modern home
– has one general purpose desktop PC
– but has several embedded systems.
• More prevalent in industrial sectors
– Dozens of embedded computers in modern
automobiles
– chemical and nuclear power plants
© Krithi Ramamritham / Kavi Arya
27
Embedded Applications
An embedded system typically has a digital signal
processor and a variety of I/O devices connected to
sensors and actuators.
Computer (controller) is surrounded by other subsystems,
sensors and actuators
Computer -- Controller's function is :
• to monitor parameters of physical processes
of its surrounding system
• to control these processes whenever needed.
© Krithi Ramamritham / Kavi Arya
28
Simple Examples
A simple thermostat controller
• periodically reads the temperature of the
chamber
• switches on or off the cooling system.
a pacemaker
• constantly monitors the heart
• paces the heart when heart beats are missed
© Krithi Ramamritham / Kavi Arya
29
Open loop temperature control
Closed loop temperature control
© Krithi Ramamritham / Kavi Arya
30
Feedback Control
Feedforward Control
© Krithi Ramamritham / Kavi Arya
31
Example: Elevator Controller
© Krithi Ramamritham / Kavi Arya
32
Remote Camera-based Survelliance
•
Observers and the observed sites
connected through a network.
•
Input from sites displayed at
observers' end at regular
intervals.
•
Need: System should capture,
process and transmit images at
regular intervals, predictably
© Krithi Ramamritham / Kavi Arya
33
When there is an alarm
• Observer redirects one or more cameras to
zoom in on to a specific part of a site.
• Sends commands with the necessary
pan/tilt/zoom parameters across the network.
• Cameras retarget their views within bounded
time and start transmitting as before, scenes
from the chosen location.
© Krithi Ramamritham / Kavi Arya
34
What do we need?
• timely transmission of user needs from observer to
camera.
• camera platform retargeting the camera within bounded
time.
• camera capturing images at regular intervals
• images sent to observers predictably across the
network
© Krithi Ramamritham / Kavi Arya
35
Functional Design & Mapping
F2
F1
F5
Functional
Design
Source:
Ian Phillips, ARM
F4
VSIA 2001
F3
Architectural
Design
HW1
Threa
d
(F2)
(F5)
(F3)
(F4)
HW2
HW3
HW4
RTOS/Drivers
Hardware Interface
© Krithi Ramamritham / Kavi Arya
36
Examples of Embedded Systems
We will look at the details of
• A simple Digital Camera
• Digital Flight Control
• Plastic Injection Molding
What the future holds…
e.g., automotive electronics
© Krithi Ramamritham / Kavi Arya
37
Digital camera…
• Only recently possible
– Systems-on-a-chip
• Multiple processors and memories on one IC
– High-capacity flash memory
© Krithi Ramamritham / Kavi Arya
38
Designer’s perspective: two key
•
tasks
Processing images and storing in memory
•
•
When shutter pressed:
– Image captured
– Converted to digital form by charge-coupled
device (CCD)
– Compressed and archived in internal memory
Uploading images to PC
•
•
Digital camera attached to PC
Special software commands camera to transmit archived
images serially
© Krithi Ramamritham / Kavi Arya
39
Compression
• Store more images
• Transmit image to PC in less time
• JPEG (Joint Photographic Experts Group)
© Krithi Ramamritham / Kavi Arya
40
Requirements Specification
• System’s requirements – what system should do
– Nonfunctional requirements
• Constraints on design metrics (e.g., “should use
0.001 watt or less”)
– Functional requirements
• System’s behavior (e.g., “output X should be
input Y times 2”)
– ….
© Krithi Ramamritham / Kavi Arya
41
Requirements Specification…
Initial specification is general - from marketing dept.
• E.g., short document detailing market need for a low-end digital camera
that:
– captures and stores at least 50 low-res images and uploads to
PC,
– costs around $100 with single medium-size IC costing less that
$25,
– has long as possible battery life,
– expected sales vol. =200,000 if mkt entry < 6 mths
– 100,000 if between 6 and 12 months,
– insignificant sales beyond 12 months
© Krithi Ramamritham / Kavi Arya
42
Nonfunctional requirements
• Design metrics of importance based on initial
specification
– Performance: time required to process image
– Size: number of elementary logic gates (2-input NAND
gate) in IC
– Power: measure of avg. electrical energy consumed while
processing
– Energy: battery lifetime (power x time)
© Krithi Ramamritham / Kavi Arya
43
Nonfunctional requirements…
• Constrained metrics
– Values must be below (sometimes above) certain threshold
• Optimization metrics
– Improved as much as possible to improve product
• Metric can be both constrained and optimization
© Krithi Ramamritham / Kavi Arya
44
Nonfunctional requirements…
• Power
– Must operate below certain temperature (cooling fan not
possible)
– Therefore, constrained metric
• Energy
– Reducing power or time reduces energy
– Optimized metric: want battery to last as long as possible
© Krithi Ramamritham / Kavi Arya
45
Nonfunctional requirements…
• Performance
– Must process image fast enough to be useful
– 1 sec reasonable constraint
• Slower would be annoying
• Faster not necessary for low-end of market
– Therefore, constrained metric
• Size
– Must use IC that fits in reasonably sized camera
– Constrained and optimization metric
• Constraint may be 200,000 gates, but smaller would be cheaper
© Krithi Ramamritham / Kavi Arya
46
Informal functional specification
• Flowchart breaks functionality
down into simpler functions
CCD
input
• Each function’s details
described in English
• Low quality image has
resolution of 64 x 64
• Mapping functions to a
particular processor type not
done at this stage
© Krithi Ramamritham / Kavi Arya
Zero-bias
adjust
DCT
Quantize
yes
no
Archive in
memory
yes
More
8×8
blocks?
no
Done?
Transmit
serially
serial output
e.g., 011010...
47
Informal functional specification
Zero-bias
adjust
CCD
input
DCT
Quantize
yes
no
Archive in
memory
yes
© Krithi Ramamritham / Kavi Arya
More
8×8
blocks
?
no
Done
?
Transmit
serially
serial output
e.g., 011010...
48
Refined functional specification
• Refine informal specification
into one that can actually be
executed
• Can use C-like code to describe
each function
– Called system-level model,
prototype, or simply model
– Also is first implementation
Executable model of
digital camera
10101101
01101010
10010101
101...
CCD.C
CCDPP.
C
Image
file
CNTRL.
C
CODEC.
C
101010101
010101010
101010101
0...
UART.C
output
file
© Krithi Ramamritham / Kavi Arya
49
Design
• Determine system’s architecture
– Processors
• Any combination of single-purpose
(custom or standard) or general-purpose processors
– Memories, buses
• Map functionality to that architecture
– Multiple functions on one processor
– One function on one or more processors
© Krithi Ramamritham / Kavi Arya
50
Design..
• Implementation
– A particular architecture and mapping
– Solution space is set of all implementations
• Starting point
– Low-end general-purpose processor connected to flash memory
• All functionality mapped to software running on processor
• Usually satisfies power, size, time-to-market constraints
• If timing constraint not satisfied then try:
– use single-purpose processors for time-critical functions
– rewrite functional specification
© Krithi Ramamritham / Kavi Arya
51
Implementation 1: Microcontroller alone
•
•
•
•
•
Low-end processor could be Intel 8051 microcontroller
Total IC cost including NRE about $5
Well below 200 mW power
Time-to-market about 3 months
However…
© Krithi Ramamritham / Kavi Arya
52
Implementation 1: Microcontroller
alone…
• However, one image per second not possible
– 12 MHz, 12 cycles per instruction
• Executes one million instructions per second
– CcdppCapture has nested loops resulting in 4096 (64 x 64)
iterations
• ~100 assembly instructions each iteration
• 409,000 (4096 x 100) instructions per image
• Half of budget for reading image alone
– Would be over budget after adding compute-intensive DCT and
Huffman encoding
© Krithi Ramamritham / Kavi Arya
53
Implementation 2:
Microcontroller and CCDPP
EEPROM
SOC
© Krithi Ramamritham / Kavi Arya
UART
RAM
8051
CCDPP
54
Implementation 2:
Microcontroller and CCDPP
EEPROM
SOC
UART
8051
RAM
CCDPP
• CCDPP function on custom single-purpose processor
– Improves performance – less microcontroller cycles
– Increases NRE cost and time-to-market
– Easy to implement: Simple datapath, Few states in controller
• Simple UART easy to implement as single-purpose processor also
• EEPROM for program memory and RAM for data memory added as well
© Krithi Ramamritham / Kavi Arya
55
Microcontroller
Block diagram of Intel 8051 processor core
4K ROM
Instruction
Decoder
Controller
ALU
128
RAM
• Synthesizable version of Intel 8051 available
– Written in VHDL
– Captured at register transfer level (RTL)
• Fetches instruction from ROM
• Decodes using Instruction Decoder
• ALU executes arithmetic operations
– Source and destination registers reside in RAM
• Special data movement instructions used to load and store
externally
• Special program generates VHDL description of ROM from output
of C compiler/linker
To External Memory Bus
© Krithi Ramamritham / Kavi Arya
56
Implementation 2:
Microcontroller and CCDPP
• Analysis of implementation 2
– Total execution time for processing one image:
• 9.1 seconds
– Power consumption:
• 0.033 watt
– Energy consumption:
• 0.30 joule (9.1 s x 0.033 watt)
– Total chip area:
• 98,000 gates
© Krithi Ramamritham / Kavi Arya
57
Implementation 3: Microcontroller
and CCDPP/Fixed-Point DCT
• 9.1 seconds still doesn’t meet performance constraint of 1
second
• DCT operation prime candidate for improvement
– Execution of implementation 2 shows microprocessor spends most
cycles here
– Could design custom hardware like we did for CCDPP
• More complex so more design effort
– Instead, will speed up DCT functionality by modifying behavior
© Krithi Ramamritham / Kavi Arya
58
DCT floating-point cost
• Floating-point cost
– DCT uses ~260 floating-point operations per pixel transformation
– 4096 (64 x 64) pixels per image
– 1 million floating-point operations per image
– No floating-point support with Intel 8051
• Compiler must emulate
– Generates procedures for each floating-point operation:
mult, add
– Each procedure uses tens of integer operations
– Thus, > 10 million integer operations per image
– Procedures increase code size
• Fixed-point arithmetic can improve on this
© Krithi Ramamritham / Kavi Arya
59
Implementation 3: Microcontroller
and CCDPP/Fixed-Point DCT
• Analysis of implementation 3
– Use same analysis techniques as implementation 2
– Total execution time for processing one image:
• 1.5 seconds
– Power consumption:
• 0.033 watt (same as 2)
– Energy consumption:
• 0.050 joule (1.5 s x 0.033 watt)
• Battery life 6x longer!!
– Total chip area:
• 90,000 gates
• 8,000 less gates (less memory needed for code)
© Krithi Ramamritham / Kavi Arya
60
Implementation 4:
Microcontroller and CCDPP/DCT
EEPROM
SOC
CODEC
RAM
8051
UART
CCDP
P
• Performance close but not good enough
• Must resort to implementing CODEC in hardware
– Single-purpose processor to perform DCT on 8 x 8 block
© Krithi Ramamritham / Kavi Arya
61
Implementation 4:
Microcontroller and CCDPP/DCT
• Analysis of implementation 4
– Total execution time for processing one image:
• 0.099 seconds (well under 1 sec)
– Power consumption:
• 0.040 watt
• Increase over 2 and 3 because SOC has another processor
– Energy consumption:
• 0.00040 joule (0.099 s x 0.040 watt)
• Battery life 12x longer than previous implementation!!
– Total chip area:
• 128,000 gates, significant increase over previous implementations
© Krithi Ramamritham / Kavi Arya
62
Digital Camera -- Summary
• Digital camera example
– Specifications in English and executable language
– Design metrics: performance, power and area
• Several implementations
–
–
–
–
Microcontroller: too slow
Microcontroller and coprocessor: better, but still too slow
Fixed-point arithmetic: almost fast enough
Additional coprocessor for compression: fast enough, but expensive and
hard to design
– Tradeoffs between hw/sw
© Krithi Ramamritham / Kavi Arya
63
Summary of
implementations
Implementation 2 Implementation 3 Implementation 4
9.1
1.5
0.099
• Implementation 3 Performance (second)
0.033
0.033
0.040
Close performance Power (watt)
Size (gate)
98,000
90,000
128,000
Cheaper
0.30
0.050
0.0040
Less time to build Energy (joule)
• Implementation 4
– Great performance and energy consumption
– More expensive and may miss time-to-market window
• If DCT designed ourselves then increased NRE cost and time-tomarket
• If existing DCT purchased then increased IC cost
• Which is better?
© Krithi Ramamritham / Kavi Arya
64
2. Flight Simulator
CLIENT - pilot
SERVER - simulator
Constraints on responses to pilot inputs, aircraft state updates
© Krithi Ramamritham / Kavi Arya
65
Time Periods to meet Timing Requirements
CLIENT
Requirement
Continuous pilot
inputs should be
polled at rates
greater than 16 ms
© Krithi Ramamritham / Kavi Arya
SERVER
Choice Made
The time period of the
writer on Client should
be less than 16 ms
Rationale
The writer thread on
the Client polls for the
pilot inputs from the
joystick
66
Time Periods to meet Timing Requirements…
CLIENT
Requirement
The state of the
aircraft is to be
advanced at 12.5
ms time steps
© Krithi Ramamritham / Kavi Arya
SERVER
Choice Made
Rationale
The time period of the
Flight Dynamics
thread on the Server
is 12.5 ms
The flight dynamics
thread on the Server
advances the state of
the system
67
Time Periods to meet Timing Requirements…
Requirement
Choice Made
Response time for
pilots should be less
than 150 ms for
commercial aircrafts
and 100 ms for
fighter aircrafts
Reader and Writer
threads on Server, and
the Reader thread on the
Client should be as fast
as the system permits.
(Time period of 4ms in
our case)
© Krithi Ramamritham / Kavi Arya
Rationale
• Delay in data transfer at
these threads increases
the response time
• These threads should be
interrupt driven in order to
minimize the response time
68
Example: Injection Molding
–Keep plastic at proper temperature (liquid, not boiling)
–Control injector solenoid (make sure that the motion of the
solenoid terminates before the piston reaches the end of its travel.
Source: “Laboratory for Perceptual Robotics, UMass” Copyright 1996 by Roderic A. Grupen
© Krithi Ramamritham / Kavi Arya
69
Controlling a reaction
• we know:
– if temperature too high, it explodes
– maximum rate of temperature increase
– rate of cooling
• events:
– temperature change
– temperature > safe threshold
• we can derive:
– how often we have to check temperature
– when we have to finish cooling
© Krithi Ramamritham / Kavi Arya
70
Example – Injection Molding (cont.)
– Timing constraints
© Krithi Ramamritham / Kavi Arya
71
Example – Injection Molding (cont.)
– Concurrent control tasks
© Krithi Ramamritham / Kavi Arya
72
Examples of Embedded Systems
We looked at details of
• A simple Digital Camera
• Digital Flight Control
• Plastic Injection Molding
The world gets exciting…
e.g. Automotive electronics
© Krithi Ramamritham / Kavi Arya
73
Automotive
Electronics
© Krithi Ramamritham / Kavi Arya
74
Cruise Control
• Controls car speed
• Actuates the throttle valve by
a cable connected to an
actuator, instead of by
pressing a pedal.
• The throttle valve controls the
power and speed of the
engine by limiting how much
air the engine takes in .
© Krithi Ramamritham / Kavi Arya
75
Control Architecture for Cruise Control
© Krithi Ramamritham / Kavi Arya
76
State Machine for Activation
© Krithi Ramamritham / Kavi Arya
77
Adaptive Cruise Control with Driver Alert
•
•
•
•
•
Helps to reduce the need for drivers to manually adjust speed or disengage
cruise control when encountering Slower traffic.
Automatically manages vehicle speed to maintain a distance set by the
driver.
Alerts drivers when slower traffic is detected in the path.
Audible and visual alerts warn the driver when braking is necessary to avoid
slower moving vehicles ahead.
Drivers can adjust system sensitivity to their preferred driving style.
© Krithi Ramamritham / Kavi Arya
78
Web Servers… get smaller
© Krithi Ramamritham / Kavi Arya
79
iPic : Tiny Web-Server
2mm*2mm,
PIC 12c508
512b ROM, 24b RAM,
6bits IO, 4MHz RC
© Krithi Ramamritham / Kavi Arya
80