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


Grade Distribution – Fall 2014

A: 6 A-: 6 B+: 15 B: 10 C: 2 F: 2

Spring 2015, arz


Outline

Embedded systems Real-time-systems Taxonomy of real-time embedded

systems Example applications

Spring 2015, arz


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


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


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


Microcontroller-Based Embedded Computer

~100 KB

ROM or Flash to hold programFlash ~256 KB

ARM Core ~ 100 MHz

Spring 2015, arz


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


Efficiency

Real-time embedded systems must be efficient

Code-size efficient

Run-time efficient

Weight efficient

Cost efficient

Energy efficient

Spring 2015, arz


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


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


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


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


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


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


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


Process Control

Industrial automation Plant monitoring and production control Similar to control systems but with

emphasis on management

Spring 2015, arz


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


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


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


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


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


E-Business

Information processing systems

ATM Cash registers Scanners Credit-card readers

Often the interface behind a database

Automation and convenience

Spring 2015, arz


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


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


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


Hardwired Processing

FInput{X}

Output{Y=F(X)}

•Special-purpose processor

•A different computation requires rewiring

Custom Hardware

Spring 2015, arz


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


Von Neumann Machine

MainMemory

ALU/Datapath

Control Unit

Input/Output CPU

Spring 2015, arz


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


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


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


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


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)

Spring 2015, arz


Summary: MIPS Instruction Formats

opcode rs rt

6 5 5

rd

5

shamt

5

func

6

R-Type Format

opcode rs rt immediate

6 5 5 16

I-Type Format

opcode immediate

6 26

J-Type Format

spring 2015, arz1 cpe555a: real-time embedded systems lecture 1 ali zaringhalam stevens institute of...

Documents