Spring 2015, arz1 CPE555A: Real-Time Embedded Systems Lecture 1 Ali Zaringhalam Stevens Institute of...
-
Upload
nathaniel-bryan -
Category
Documents
-
view
215 -
download
0
Transcript of Spring 2015, arz1 CPE555A: Real-Time Embedded Systems Lecture 1 Ali Zaringhalam Stevens Institute of...
Spring 2015, arz 1
CPE555A:Real-Time Embedded Systems
Lecture 1Ali Zaringhalam
Stevens Institute of Technology
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 2
Grader
Neha Raje: [email protected]
2
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 3
Grade Distribution – Fall 2014
A: 6 A-: 6 B+: 15 B: 10 C: 2 F: 2
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 4
Outline
Embedded systems Real-time-systems Taxonomy of real-time embedded
systems Example applications
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 5
General-Purpose Computer System
A general-purpose computer such as a desktop or laptop can be used for a variety of applications (e.g. word processing, streaming audio, DB)
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 6
Embedded Computer System
An embedded computer system is a component of a larger system
It is programmed to serve a single set of functions It generally interacts with the environment and
performs a set of repeated control and monitoring tasks
Examples include computers embedded in TV, microwave oven, medical devices, cars, network routers, etc.
There are a lot more embedded computing devices than desktops, laptops, workstations
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 7
General-Purpose Computer
Up to 1000 GB StorageCD/DVD
Intel Pentium 3-4 GHz3-8MB Cache
Video card
10/100/1000 Ethernet & WiFi
~8 GB RAM
~100 W Power
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 8
Microcontroller-Based Embedded Computer
~100 KB
ROM or Flash to hold programFlash ~256 KB
ARM Core ~ 100 MHz
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 9
Large Embedded Systems
Embedded doesn’t mean small Large embedded systems such as network
switches and routers don’t use microcontrollers
CPU is typically in 100’s of MHz 500MB-1 GB RAM 250-500 MB Flash Power consumption could be an issue
They are embedded systems like their smaller counterparts in the sense that they perform a single well-defined set of tasks
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 10
What Is a Real-Time System?
A computer program/algorithm has inputs and outputs. The response/output to a given input defines the program behavior.
Sorting algorithm: sort the input and provide as output There are many sort algorithms with different average
and worst-case complexity (O(n), O(nlogn), etc.) In a real-time system, the behavior must be
both logically correct and produced at the correct instant of time.
If the deadline is missed, the behavior is considered incorrect.
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 11
System/Environment Interfaces
A real-time system reacts to input from the environment (user and the controlled object)
“Real” time means that the reaction of the system to external events must occur during its evolution
Using the same time scale and clock
Real-Time System
Controlled Object
User
User Interface
ControlInterface
• Pedestrian• Car driver• Network operator• Etc.
• Traffic light• Brake system• Switching device• Etc.
• Keyboard/Button• Display
• Sensors & actuators• Control registers
Environment
Environment
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 12
Classification of Real-Time Systems
Hard real-time vs. soft real-time Fail-safe vs. fail-operational Guaranteed timeliness vs. best-
effort Resource-adequate vs. resource-
inadequate Event-triggered vs. time-triggered
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 13
Hard vs. Soft Real-Time: Deadline
A hard real-time system must produce the result at the correct physical time. Failure to do so can have catastrophic consequence and is considered unacceptable. Nuclear power plant
A soft real-time system can miss a deadline. The result may still be useful If the deadline is missed, there will not be a
catastrophe. (e.g., multimedia)
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 14
Hard vs. Soft Real-Time: Response-Time
A hard real-time system must respond to events on the order of milliseconds (e.g., a braking system).
A soft real-time system’s response can be on the order of seconds (an ATM machine).
Hard real-time systems use specialized scheduling techniques
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 15
Hard vs. Soft Real-Time: Peak-Time Performance
A hard real-time system must meet the specified deadline under peak/worst conditions. It must be able to meet deadlines in rare-event scenarios.
Soft real-time systems are defined in terms of average behavior. Performance degradation in worst case scenarios is accepted for economic reasons
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 16
Real-Time Impact of Common Techniques
Pipelined processors with speculative execution for conditional statemets
Caching Virtual memory Compilers with optimization turned on Garbage collection Multi-tasking Networking Software component Etc. All commonly used in general-
purpose computers. Some (such as virtual memory) are never used in embedded systems.
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 17
Fail-Safe Vs. Fail-Operational
If a system can enter a “safe” state when failure occurs, the system is fail-safe Railway signaling system failure: a safe state
is to turn all lights red. Example: a watchdog timer must be stroked
at regular intervals by software. If there is a software failure, the watchdog fires, forces the system into a safe state & resets the CPU.
In a fail-operational system, a safe state cannot be identified. The system must remain operational and provide a minimal amount of guaranteed service. An airplane with a single failed engine
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 18
Guaranteed Response Time
Assumption coverage: start by defining a set of specifications for the expected system failures & a set of worst-case load assumptions.
Recovery specifications: next specify recovery strategy to meet fail-safety, fail-operational, etc.
For guaranteed response, the system must be designed to address all specified failures under peak load with the specified recovery.
The probability of unknown failure is reduced to the accuracy of the specification coverage & recovery spec.
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 19
Best-Effort System
A system that does not have the guaranteed response-time properties is considered a best effort system
In a best-effort system, failures are discovered through extensive integration testing. When a failure is discovered during testing, a fix is proposed and implemented
This is an ad-hoc procedure: there are always failures that are detected after system deployment.
For economic reasons, most real-time systems are best-effort unless thy have safety-critical requirements.
Troutman Postulate:The worst software bug
will be discovered six months after field test.
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 20
Resource-Adequacy
In order to have a guaranteed response time, the system must be engineered to operate under worst-case conditions You can’t use probabilistic arguments to
estimate a resource (such as RAM size) Most soft real-time systems are best-
effort and therefore not resource-adequate under worst-case conditions
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 21
Event- vs. Time-Triggered
In event-triggered systems, all processing activities are driven by some event in the environment The computer system receives the event via a
CPU interrupt In time-triggered systems, all processing
activities are initiated at periodic intervals There is a single interrupt associated with a
clock to pace the system The occurrence of events in the environment
are detected via periodic polling
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 22
Dependability
Real-time systems must be dependable: it should provide the intended service for an extended interval of time
Reliability Maintainability Availability Safety Security
Even perfectly designed systems can fail if the assumptions about the workload and possible errors turn out to be wrong.
Making the system dependable must not be an after-thought, it must be considered from the very beginning
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 23
Reliability Measure
Reliability R(t) = probability of system working correctly provided that is was working at t=0
Mean Time To Failure (MTTF): average period of time until a failure occurs
Failure rate (FIT): a measure of the frequency with which the system fails; expressed in failures per hour
1 FIT means that the MTTF is 109 hours (115,000 years) In general the failure rate is time-dependent. A car is more
likely to fail after 10 years. But typically a fixed FIT rate is used as a measure of
reliability R(t) = exp[-(t-t0)] where =1/MTTF Ultra-high reliable systems typically have a = 10-9
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 24
Safety Measure
How safe is a computer-controlled braking system in a car?
The failure is critical in the sense that the cost is immeasurable (loss of life)
The safety of a system with respect to a critical failure is also measured in terms of MTTF of the specific failure
A car typically operates a few hours a day. A failure rate of = 10-9 translates into about one failure per million cars per year
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 25
Maintainability Measure
Maintainability is a measure of the time interval to repair a system after a failure has occurred Repair could take human intervention or it
could be autonomous Example of autonomous repair: a computer
software failure triggers a reset Example of human intervention: craft
dispatch Mean time to repair (MTTR) is the
average time to repair a failed system Repair rate =1/MTTR (repairs per hour)
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 26
Availability Measure
Availability is a measure of the delivery of correct service when the service fails intermittently
In a system with MTTF and MTTR A= MTTF/MTBF MTBF= MTTF+MTTR
Design tradeoff: you can increase availability by either increasing MTTF or decreasing MTTR
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 27
Example - 1
A telecom system deployed in the field has a MTTF of 100,000 hours (~11 years) assuming a hardware failure
FIT rate=10,000. If a blade fails, it requires dispatch of maintenance crew
to replace the blade. This takes about 4 hours. What is the availability rate?
MTBF=100000+4=100004 hours A=MTTF/MTBF=100000/100004=0.99996 This system is referred to as meeting four nines Down-time per year: 365*24*60*(1-0.99996)=21 minutes
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 28
Example - 2
Typically the availability requirement for telecom systems is five nines
What can be done to increase availability? MTBF= MTTF+MTTR; A= MTTF/MTBF
Common strategy is to reduce MTTR by providing a redundant blade which can be placed in service as a standby
Suppose it takes a minute to do a failover switch (for a hot standby it is instantaneous)
Availability=100000/(100000+1/60)=0.999999 (six nines) Assumes the redundant blade does not fail before the primary
has been replaced. Double failures are not covered. Down-time per year: 365*24*60*(1-0.999999)=0.5 minute For five nine systems it is about 5 minute downtime/year
For more information on high availability, see http://en.wikipedia.org/wiki/High_availability
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 29
Security
Embedded systems must protect against unauthorized access and denial-of-service (DOS) attacks
File tampering Code tampering Etc.
Cryptographic theft-avoidance systems for cars (ignition locking)
Authentication network protocols (e.g., 802.1X) DOS attacks on servers and routers
Policing traffic destined for the CPU from the network Trusted Platform Module (TPM) is the specification for a
crypto-processor http://en.wikipedia.org/wiki/Trusted_Platform_Module
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 30
Efficiency
Real-time embedded systems must be efficient
Code-size efficient
Run-time efficient
Weight efficient
Cost efficient
Energy efficient
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 31
Rare Events
A rare event is an even that “rarely” happens It could be something that was not anticipated at
design time or detected during the test phase It can lead to silent failures: failures that are not
alarmed or logged Example: a random bit flip in an ASIC due to a
manufacturing process defect Lessons:
Read the specifications of your device carefully and look for integrity measures on memory, busses etc.
Account for them in your design with good logs A big issue as device complexity increases
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 32
Application Areas
Hybrid embedded systems Aerospace, automobiles, robotics, process control, and
sensor nets Multimedia Consumer electronics
Appliances, office electronics, and home/office automation Network components
Bridges, routers, switches, and hubs Medical instruments
Patient monitoring, MRI, and artificial hearts E-Business
ATM, vending machines Distributed & grid computing
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 33
Hybrid Embedded Systems
Computation systems whose behavior is tightly integrated with the physical world Example: the behavior of an unmanned aerial
vehicle (UAV) can be modeled by a combination of differential equations (the aerodynamics and low level feedback controllers) and a finite state automata (high level flight path decisions, such as to ascend or descend).
Behavior is governed by both continuous-state dynamics from the physical world and discrete-state dynamics from the computation
Passage of time during computation affects the state of the physical world
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 34
Aerospace
Flight control Stability Anti-collision systems
Positioning & navigation Global Positioning System
(GPS) Inertial navigation system (INS)
Instrumentation Data acquisition, display,
processing, and archive Radar Communication
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 35
Automobiles
Engine management Fuel, ignition, timing
Emission control Instrumentation Data acquisition, display, processing Safety & stability
Airbags Anti-Lock Braking Systems (ABS) Electronic Stability Control (ESC) Theft prevention with smart keys Blind-angle alert systems
Entertainment & comfort Radio Heat & A/C
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 36
Automobiles
Premium-class automobile Millions of LOC in a premium class
automobile Execute on 70-100 μP Electronics & SW cost is ~40% of
the car’s cost, and rising Low-end cars
30-50 μP Processors are networked
throughout the car Source:
http://spectrum.ieee.org/green-tech/advanced-cars/this-car-runs-on-code
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 37
Robotics
Implies autonomous operation
N physical degree of freedom
Artificial intelligence Control heavy Mission oriented
Repair, search, rescue, investigate, and perform physically difficult tasks
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 38
Process Control
Industrial automation Plant monitoring and production control Similar to control systems but with
emphasis on management
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 39
Sensor Nets
Many sensor nodes each capable (but limited) of sensing, computation/storage, and communication Structure safety Search and rescue Military use
Energy Efficient Distributed
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 40
Multimedia
Functions include Signals, analog to digital conversion,
quantization, sampling, processing, and digital to analogue conversion
Compression Images, audio, video
Virtual Reality Presentation Quality of service
Jitter-intolerance
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 41
Consumer Electronics
Home appliances Microcontroller-based Future: add networking (HeMS)
Office electronics Scanner/Printer/Fax
Home/office automation Automated home or office with lights and appliances
that operate by themselves or with minimal effort Internet of Things
http://en.wikipedia.org/wiki/Internet_of_Things Typically has embedded systems hanging off the
end
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 42
Network Components
Switching LANs Bridge: connects two parts of the same multicast
domain/subnet Router: links nodes of different subnets
Switch large volumes of data at high-speed line rate (1/10/100 Gbps)
Packet classification and filtering based on packet header
Deep packet inspection Quality of Service (policing and shaping in packet
networks) An embedded computer controls the datapath
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 43
Medical Instruments
Perform diagnosis (screening/evaluatio)
Data collection Appraisal of that data
Observation or monitoring Sensing and
instrumentation Accuracy and precision
Other applications: Radiation therapy Artificial hearts, arms, legs, …
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 44
E-Business
Information processing systems
ATM Cash registers Scanners Credit-card readers
Often the interface behind a database
Automation and convenience
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 4545
Elements of Computer Architecture
Instruction Set Architecture (ISA) how to tell the processor what to do?
Microarchitecture includes CPU internal organization, memory
hierarchy, etc.
Hardware Implementation circuit design packaging etc.
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 4646
Instruction Set Architecture
Interface between machine & “programmers” machine’s Application Programming
Interface (API) The“programmers” who care about this API
for the most part compiler developers care……but also ...
assembly programmers (low-level code) Real-time system developers
most programmers write portable code in high-level language and do not care about ISA
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 4747
Microarchitecture
Specification of Functional Blocks internal registers (how many, special- vs. general-purpose, etc.) Arithmetic & Logic Unit (ALU) , FP units memory organization & cache design, etc.
Specification of Interfaces Between Building Blocks interconnection structure (bus, point-to-point, etc.) data flow between instructions (register, broadcast bus, etc.) control (hardwired, microprogrammed, centralized, distributed)
Implementation of ISA whether CPU is single-cycle, multi-cycle, pipelined, etc. organization of pipeline (number of stages, functions in each
stage) single-issue, multiple-issue (superscalar), etc.
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 4848
Hardwired Processing
FInput{X}
Output{Y=F(X)}
•Special-purpose processor
•A different computation requires rewiring
Custom Hardware
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 4949
General-Purpose Processor
Input{X} Output
{Y=F(X,S)}
General-Purpose ALU
Control Signals (S)
Instruction Decoder
Instruction
CPU is a general-purpose instruction set processor
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 5050
Von Neumann Machine
MainMemory
ALU/Datapath
Control Unit
Input/Output CPU
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 5151
Von Neumann Machine: Key Concepts
Stored Program Control Storage of Both Data & Executable Instructions in Main Memory
Memory is Addressable by Location for Both Data & Executable
Control Unit Fetch & Execution of Sequential Instructions From Memory Branch Instructions
Arithmetic & Logic Unit (more generally: datapath which includes functional units for fetch & store, decode, etc.)
Arithmetic & Logical Operations on Binary Data Input/Output
Controlled by Control Unit (directly or indirectly) First Prototype: IAS in 1952
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 5252
Fetch/Execute Cycle
StartStart Fetch Next InstructionFetch Next Instruction
Execute Instruction
Execute Instruction
HandleInterrupts
(If Any)
HandleInterrupts
(If Any)
Interrupts Disabled
Inte
rru
pts
En
ab
led
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 5353
Need for Instructions We need a way to tell the processor what steps
to take to execute our program. In the Von Neumann Model this includes
fetching data from memory performing arithmetic & logical operations on the data storing the results of computation in memory performing input/output
In addition the processor must support certain high-level programming constructs. These include
modifying the sequential flow of control for if then else and case
subroutine calls to support structured programming
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 5454
Examples of InstructionsH e r e a r e s o m e e x a m p l e i n s t r u c t i o n s :
L o a d i n g d a t a f r o m a m e m o r y l o c a t i o n i n t o a r e g i s t e r
l o a d R e g i s t e r 1 , M e m o r y _ A d d r e s s
S t o r i n g d a t a f r o m a r e g i s t e r t o a m e m o r y l o c a t i o n
s t o r e R e g i s t e r 1 , M e m o r y _ A d d r e s s
A d d i n g t h e c o n t e n t s o f t w o s o u r c e r e g i s t e r s a n d s t o r i n g t h er e s u l t i n a t h i r d d e s t i n a t i o n r e g i s t e r
a d d R e g i s t e r 3 , R e g i s t e r 1 , R e g i s t e r 2 C o m p a r i n g t w o r e g i s t e r s a n d f e t c h i n g t h e n e x t i n s t r u c t i o n
b a s e d o n t h e r e s u l t o f c o m p a r i s o n ( e i t h e r s e q u e n t i a l o r f r o ma b r a n c h )
b n e R e g i s t e r 1 , R e g i s t e r 2 , I n s t r u c t i o n _ A d d r e s s
Spring 2015, arz
CPE555A – Real-Time Embedded SystemsStevens Institute of Technology 5555
RISC Instruction Set Architecture
MIPS is a flavor of the more generic class of Reduced Instruction Set Computer (RISC) Instruction Set Architecture (ISA)
Here are some examples of RISC processors ALPHA (Digital/Compaq) PA-RISC (HP) PowerPC (Motorola & IBM) SPARC (Sun Microsystems) MIPS (MIPS/Silicon Graphics) ARM (heavily used in embedded systems today)
The ISAs implemented in these machines are not quite the same but share a large set of common characteristics (to be discussed shortly)