Real-Time Embedded Systems - PowerPoint PPT Presentation

Loading...

PPT – Real-Time Embedded Systems PowerPoint presentation | free to download - id: 67be10-ZmYyZ



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Real-Time Embedded Systems

Description:

Real-Time Embedded Systems Assist. dr. Barbara Korou i Seljak Barbara.Korousic_at_ijs.si (01) 4773-363 Course synopsis Fall semester: Basics of real-time and embedded ... – PowerPoint PPT presentation

Number of Views:100
Avg rating:3.0/5.0
Date added: 12 June 2020
Slides: 91
Provided by: csdIjsSik
Learn more at: http://csd.ijs.si
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Real-Time Embedded Systems


1
Real-Time Embedded Systems
  • Assist. dr. Barbara Koroušic Seljak
  • Barbara.Korousic_at_ijs.si
  • (01) 4773-363

2
Course synopsis
  • Fall semester
  • Basics of real-time and embedded systems
  • Embedded systems modeling
  • Software and program design concepts
  • Operating systems for real-time applications

3
Course synopsis
  • Spring semester
  • Designing and developing embedded systems
  • Implementation and performance issues

4
Benefits? Learn about ...
  • ... challenges and approaches in real-time
    embedded system design
  • performance estimation of real-time embedded
    systems
  • ... current research areas

5
Basics of real-time and embedded systems
  1. Real-time systems

6
Real-time (RT) systems
  • Categories of computer systems
  • Batch has no operational deadline from event to
    system response
  • Interactive on-line quick response is
    longed-for, but not required
  • Real-time system response is required within a
    predefined timescale, otherwise the system wont
    work properly.

7
Characteristics of a batch system
  • The user pre-processes all programs and
    information at a local site, and at some
    convenient time these jobs are passed to a remote
    computer. When all jobs are finished, the results
    are transmitted back to the originating site.

8
Characteristics of an on-line system
  • Normally, access to such a system is made using
    computer-based remote terminals, and all
    transactions are handled by the central computer
    in a time-sliced fashion.
  • These systems are widely used in banking, holiday
    booking and mail-order systems.
  • Their response time depends on the amount of
    activity.

9
Characteristics of a RT system
  • A control computer detects events triggered by
    sensors, and responds over actuators within
    predefined time bounds.

10
History of real-time computing
  • The term real-time derives from its use in early
    simulation.
  • Originally, this term referred to a simulation
    that proceeded at a rate that matched that of the
    real process it was simulating.

11
RT Applications
Execution time Deadlines SW size SW complexity
Hard real-time fast ? ? ? ? ? ? ? ? ? ?
Hard real-time slow ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
Soft real-time fast ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
Soft real-time slow ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
? Low weighting ? ? ? ? High weighting
12
Hard RT Applications
  • Critical deadlines
  • Usually, low SW complexity
  • Example airbag deployment system in motor
    vehicles

fast system late deployment defeats the whole
purpose of airbag protection
13
Soft RT Applications
  • Deadlines are not critical
  • Usually, more complex and large SW man-machine
    interface
  • Examples factory
  • automation system,
  • barcode recognition
  • system

fast/slow system if fast/slow operator
response is required
14
Basics of real-time and embedded systems
  1. Real-time systems
  2. Embedded systems

15
Categories of RT systems
  • Categories of computing systems
  • General-purpose computing systems
  • Embedded systems (ESs).
  • RT systems may be general-purpose or embedded
    systems.
  • We are going to discuss RT embedded systems.

16
Characteristics of general-purpose systems
  • Broad class of applications
  • Programmable by the end user
  • Faster is better.
  • Criteria
  • Cost,
  • performance (average speed)
  • Examples personal computers, laptops,
    mainframes, servers.

17
What is an ES?
  • An embedded system is an electronic component
    within a physical system.

sensors / actuators
external process
man-machine interface
embedded system (a combination of tailored HW
SW)
reactive time-constrained environment
18
Characteristics of ESs
  • Single-functioned
  • A single system-tailored task or a very small
    number of related tasks are executed repeatedly
  • Minimal end-user intervention
  • Tightly constrained
  • Low cost, low power, small size, easy-to-use,
    etc
  • Reactive real-time
  • Continually reacts to events in the systems
    physical environment
  • Must perform certain tasks in real-time on a
    physical platform.

19
Examples of ESs in common environments (1)
20
Examples of ESs in common environments (2)
21
Short list of embedded applications
  • Consumer electronics (MP3 players, smart clothes,
    wearable devices)
  • Home appliances (microwave owens, home security
    system)
  • Office automation (modems, printers, scanners)
  • Business equipment (intruder alarm systems, POS
    terminals)
  • Automobiles (fuel injection, anti-lock brakes)
  • Aircrafts, satellites, trains, submarines
    (navigation systems)
  • Medicine (life-support systems, medical devices)
  • Telecommunication (network switches/routers, cell
    phones)
  • Automation systems (monitors, robots)

22
Microprocessor and semiconductor chips trends
23
Brief history of ESs (1)
Whirlwind computer
  • Late 1940s MIT Whirlwind computer was designed
    for real-time operations
  • Originally designed to control an aircraft
    simulator
  • In the 1960s
  • The first recognizably ES was the Apollo Guidance
    Computer (MIT Instrumentation Laboratory)
  • By the end of the 80s
  • ESs were the norm rather than the exception for
    almost all electronics devices (microcontrollers,
    I2C).

Intel 4004
24
Brief history of ESs (2)
  • Todays complex ESs are based on networks of
    distributed microprocessors that run many
    off-the-shelf operating systems and communicate
    through wired and wireless buses, LANs and WANs
  • A high-end automobile may have 100
    microprocessors
  • 4-bit microcontrollers check seat belts
  • microcontrollers run dashboard devices
  • 16/32-bit microprocessor controls engine.

25
Brief history of ESs (3)
  • What do we expect from high-performance ESs
    today?
  • Giga-ops of computing power
  • For example, cell phones that use SW-radio
    techniques will need to deliver at least 10
    billion operations per second
  • Multimedia applications.
  • It is difficult to achieve this performance level
    in the face of real-time and low power or other
    constraints.

26
Few statistical facts
  • General-purpose computers
  • Millions of units produced per year.
  • Embedded systems
  • Billions of units produced yearly (VDC Report,
    2006).
  • More than 98 of processors applied today are in
    ESs.
  • Mean age of embedded developers 39,6.

27
Students
  • Student Research area
  • Student 1
  • Student 2
  • Student 3
  • Student 4
  • Student 5
  • Student 6
  • Student 7

28
ESs modeling
  • Challenges
  • Technological build an embedded system of
    predictable functionality and quality
    (performance robustness) considering the
    systems constraints

29
How to satisfy the technological challenge?
30
Hardware design?
new computer architectures (open flexible
multi-core SoC)
31
Software design?
new software architectures (1-2 million lines
of code)
32
Control design?
novel system-level analysis, modeling methods
and tools
33
HW/SW Codesign!
Design, validation maintenance processes need
to support the high-performance HW
communication technologies!
34
HW/SW Co-design Approach
  • In the past, HW and SW design technologies were
    very different.
  • Today, synthesis approaches enable a unified view
    of HW and SW
  • Design of HW and SW can start from behavioral
    (system-level) description in sequential program
    model
  • Electronic System Level Design.

35
The Co-design Ladder (VahidGivargis, 2002)
Sequential program codes (e.g., C, VHDL, SystemC)
SW
Behavioral synthesis (1990s, 2000s)
Compilers (1960s,1970s)
Register transfers
RT synthesis (1980s, 1990s)
Assembly instructions
Logic equations/FSMs
Assemblers, linkers (1950s, 1960s)
Logic synthesis (1970s, 1980s)
Machine instructions
Logic gates
Traditional program on a programmable processor
VLSI, ASIC, or PLD implementation
HW
36
Embedded Systems Design Challenge
  • Design goal
  • Construct a system with desired functionality.
  • Key design challenge
  • Simultaneously optimize numerous design metrics
  • Time-to-prototype
  • Time-to-market
  • Maintainability
  • Correctness, reliability, safety, etc.

8 months
37
ESs modeling
  • Challenges
  • Technological build an embedded system of
    predictable functionality and quality
    (performance robustness) considering the
    systems constraints
  • Scientific integrate Electrical Engineering and
    Computer Science methodologies.

38
How to satisfy the scientific challenge?
  • Electrical engineering
  • Differential equations
  • Linear algebra
  • Probability theory
  • Sythesis
  • Theories of estimation
  • Theories of robustness
  • Computer science
  • Logic
  • Discrete structures
  • Automata theory
  • Theories of correctness
  • Verification

Lets take down the cultural wall between the
two fields!
39
Modeling (1)
  • Main steps of the ESs design
  • Definition of systems constraints /
    requirements
  • Derivation of an abstract system, i.e. a model
  • Automatic generation of a system.

40
Modeling (2)
  • However, we cannot separate computation (SW) from
    physicality (platform environment)!

41
Analytical modeling (1)
  • Analytical model is a simulation, based on an
    abstract systems representation, which
  • attempts to find analytical (equation-based)
    solutions to problems that enable the prediction
    of the systems behavior from a set of parameters
    and initial conditions.

42
Analytical modeling (2)
  • Types of analytical models
  • algorithm-based (language-based Ada, RT-Java /
    synthesis-based VHDL, Verilog),
  • equation-based (MATLAB/Simulink)
  • object-oriented,
  • dynamic simulation,
  • implementation platform independent
    (model-based)
  • ANSYS.

43
Analytical modeling (3)
  • Building blocks
  • types transistors, logic gates, functional
    components (adders), architectural components
    (processors)
  • structure changes deterministic, or
    probabilistic
  • composition interconnected, inherently parallel,
    determined by data flows
  • formal semantics transfer functions, typically
    specified by equations

Examples netlists, dataflow diagrams, and
other notations for describing systems
structure.
44
Analytical modeling (4)
  • Embedded MATLAB
  • automatic code generation of C and C objects,
    optimized for ESs.

45
Computational modeling (1)
  • Computational model is a computer program, or a
    network of computers, which attempts to simulate
    an abstract model of a particular system
  • simulation is combined with the reality of actual
    events
  • solutions to the problem are machine-based.

46
Computational modeling (2)
  • Types of computational models
  • machine-based (RT/UML, AADL)
  • object-oriented,
  • dynamic simulation,
  • more generic (execution semantics independent)
    model-based.

47
Computational modeling (3)
  • Building blocks
  • types objects, threads
  • structure changes dynamically
  • composition sequential, determined by control
    flows
  • formal semantics abstract machine (virtual
    machine / automaton)

Examples programs, state machines, and other
notations for describing system dynamics.
48
Computational modeling (4)
  • Be realistic about the UML
  • Lack of analytical tools for computational models
    to deal with physical constraints
  • Generally, code is still individually designed,
    not automatically generated.

49
Analytical vs. computational modeling
Analytical modeling Computational modeling
Concurrency / naturally deals with concurrency -
Physical constraints -
Nondeterminism - / struggles with partial incremental specifications / supports nondeterministic abstraction hierarchies
Computational complexity - / rich theory
Analytical synthesis techniques -
Automatic generation of a system / directly executable models
50
Software and program design concepts
  • SW Prototyping

51
What do we want in our SW?
  • Correctness
  • the static property that a program is consistent
    with its specification
  • Reliability
  • the extend to which a program can be expected to
    perform its intended function with required
    precision
  • Safety
  • the extend to which a program is concerned with
    the consequences of failure.

We wish that our SW is dependable, is delivered
on time and is done within budget!
52
How to achieve this? (1)
  • Develop a clear statement of systems
    requirements.
  • Ensure that the design solution is capable of
    achieving this.
  • Organize the development so that the project is
    manageable.
  • Organize the development so that timescales can
    be met.
  • Make sure that the design can be managed without
    major rewrites.
  • Design for testability.
  • Minimize risks by using tried and trusted
    methods.
  • Ensure that safety is given its correct priority.
  • Make sure that the project doesnt completely
    rely on particular individual.
  • Produce a maintainable design.
  • ?

53
How to achieve this? (2)
Systems requirements
functional
non-functional
non-functional
non-functional
What its supposed to do
Dos and donts
How it fits in with its environment
How well it must do it
function
constraints
interfaces
performance
real-world interfaces
SW world interfaces
man-machine
plant
OSs
databases
54
How to achieve this? (3)
virtual prototyping
55
OSs for RT Applications
  • Basics of RTOSs

56
Role of OSs
  • Typical OS configuration
  • OS is an organized collection of SW extensions of
    HW that serve as
  • control routines for operating a computer
  • an environment for execution of programs.
  • Typical embedded configuration

User programs
OS
HW
57
OS hierarchy
  • Typical OS configuration
  • Typical embedded configuration
  • OS kernel gives us control over the resources
  • No background processes
  • Bounded number of tasks
  • OS kernel gives us control over timing by
    allowing
  • Manipulation of task priorities

58
Terminology tasks functions (1)
  • A task is a process that repeats itself
  • Loop forever
  • Essential building block of real-time SW systems
  • A job is an instance of a task.
  • A function is a procedure that is called. It
    runs, then exits and may return a value.

59
Terminology tasks functions (2)
  • Periodic tasks
  • Time-driven characteristics are known a priori
  • Task ti is characterized by (Ti, Ci)
  • For example, task monitoring temperature of a
    patient.
  • Aperiodic tasks
  • Event-driven characteristics are not known a
    priori
  • Task ti is characterized by (Ci, Di) and some
    probabilistic profile for arrival patterns (e.g.
    Poisson model)
  • For example, task activated upon detecting change
    in patients condition.
  • Sporadic Tasks
  • Aperiodic tasks with known minimum inter-arrival
    time (Ti, Ci).

60
Terminology tasks functions (3)
  • Tasks parameters
  • Release time the time when a job is ready
  • Computation time usually Worst-Case Execution
    Time (Ci)
  • Deadline the time when a job should be ready
    (Di)
  • Period Period or minimum interarrival time
  • Priority static or dynamic
  • Blocking time worst-case
  • Response time (latency) the time difference
    between the release time of a job and the
    completition time of the job.

61
Terminology Processes Threads
  • In traditional multitasking OSs, processes are
    typically independent, carry considerable state
    information, have separate address spaces, and
    interact only through system-provided
    inter-process communication mechanisms.
  • Multiple threads, on the other hand, typically
    share the state information of a single process,
    and share memory and other resources directly.
  • Context switching between threads in the same
    process is typically faster than context
    switching between processes.
  • A thread (of execution) is a way for
  • a program to fork (or split) itself into
  • two or more (pseudo-)simultaneously
  • running tasks.

62
Basic RTOS kernel functions
  • Task scheduler to determine which task will run
    next in a multitasking system
  • Task dispatcher to perform necessary
    book-keeping to start a task
  • Control of shared resources to support intertask
    communication.

63
OSs for RT Applications
  • Basics of RTOSs
  • Scheduling modeling assumptions.

64
RTOS kernel design strategies (1)
  • Simple options
  • Pooled loop systems
  • A single and repetative instruction tests a flag
    that indicates whether or not an event has
    occured
  • No scheduling and intertask communication needed
  • Processor is dedicated to handling the data
    channel.
  • Interrupt-driven systems
  • Processing continues until interrupted by
    external events
  • After interrupt has been serviced, processing
    resumes where it left off.

65
Interrupt handling
  • An interrupt is a SW or HW signal to the
    processor,
  • indicating that something urgent has happened
  • Current task wants to sleep or get I/O
  • Scheduler wants to run a different task now
  • Sensors detect external events
  • Interrupts can be
  • prioritized,
  • disabled,
  • masked.

interrupts
ISR
ISR
ISR
Processor must check for interrupts very
frequently.
66
RTOS kernel design strategies (2)
  • Extended options
  • Multitasking
  • Foreground / background systems
  • Full featured RTOSs

67
Multitasking (1)
  • Separate tasks share one or more processors.
  • Each task executes within its own context
  • Owns CPU
  • Sees its own variables
  • May be interrupted
  • Tasks may interact to execute as a whole program.

68
Multitasking (2)
  • Ways to implement multitasking
  • Cyclic Executive (statically ordered tasks /
    threads)
  • Round Robin (each task is assigned a fixed time
    slice)
  • These ways are not perfect
  • High priority tasks hog resources and starve low
    priority tasks
  • Low priority tasks share a resource with high
    priority tasks and block high priority tasks.
  • How does a RTOS deal with some of these issues?
  • Rate Monotonic / Earliest Deadline Systems
  • Priority Inheritance

69
Rate Monotonic systems (Liu Layland, 1973)
  • General characteristics
  • Priority-based pre-emptive static scheduling
  • Highest-priority ready task runs first
  • Task priority P is set according to its
    periodicity Tp P1/ Tp
  • Tasks are equally important
  • SCHED_FIFO (POSIX)
  • Cons
  • It cannot deal with aperiodic tasks
  • Task deadline and period are considered to be
    synonymous
  • Task worst-case execution time is constant
  • Tasks are independent, i.e. non-interacting.
  • Pros
  • Zero context-switch time
  • Task set scheduled using RMS is guaranteed to be
    feasible provided its utilization does not exceed
    0.693 (full utilization).

70
Rate Monotonic systems (2)
  • Utilization
  • The percentage of available processor time spent
    executing tasks (Ut)
  • The lowest utilization figure U for n tasks is
    Un(21/n-1).

task execution time (ms) deadline / period (ms)
1 1 8
2 2 5
3 2 10
Ut1/82/52/100.725 U 3(21/3-1)0.78 Since
Ut lt U ... the system is schedulable!
71
Earliest Deadline First (EDF)
  • General characteristics
  • Priority-based pre-emptive dynamic scheduling
  • Highest-priority ready task runs first
  • Task priority P is set according to its due time
    Tg P1/ Tg
  • Tasks are equally important
  • Cons
  • Tasks priorities need to be recalculated at
    every timer interrupt
  • Task set scheduled using EDF is guaranteed to be
    feasible even if its utilization is 1.
  • Pros
  • Task may miss its deadline.

72
Foreground / background systems
  • Most common hybrid solution for embedded
    applications.
  • Involve interrupt-driven (foreground)
    non-interrupt-driven (background) processes
  • Anything non-time-critical should be in
    background.

73
OSs for RT Applications
  • Basics of RTOSs
  • Scheduling modeling assumptions
  • Interprocess communication.

74
Priority inversion
  • Problem
  • Task T1 of high priority and task T3 of low
    priority share a resource
  • Task T1 is blocked when task T3 runs (priority
    inversion)
  • Task T1 will be blocked for longer if task T2 of
    medium priority comes along to keep task T3 from
    finishing
  • Solution
  • A good RTOS would sense this condition and
    temporarily promote task T3 to the high priority
    of task T1 (priority inheritance).

75
How to overcome priority inversion?
  • Problem
  • Solution (priority ceiling protocol)

T3 inherits T1s priority so it can finish and
then T1 can have the resource
76
OSs for RT Applications
  • Basics of RTOSs.
  • Scheduling modeling assumptions.
  • Interprocess communication.
  • Power management.

77
Power optimization
  • Power management
  • determines how system resources are going to be
    used to satisfy the power consumptions
    requirement.
  • RTOS may reduce power by shutting down units
  • Entering and leaving the power-down mode requires
    both, energy and time.

78
Power management policies (1)
  • Request-driven
  • Power up once request is received
  • Con Adds delay to response.
  • Predictive shutdown
  • Due time to next request is predicted
  • Pro May start up in advance of request in
    anticipation of a new request
  • Con If prediction is wrong, an additional delay
    may be incured while starting up.

79
Power management policies (2)
  • Probabilistic shutdown
  • Assume service requests are probabilistic
  • Optimize expected values
  • power consumption
  • response time.
  • Simple probabilistic shut down after time Ton,
    turn back on after waiting for Toff.

80
Advanced Configuration and Power Interface
  • ACPI (open standard for power management
    services).

application
device drivers
RTOS kernel
power management
ACPI BIOS
Hardware platform
81
OSs for RT Applications
  • Basics of RTOSs.
  • Scheduling modeling assumptions.
  • Interprocess communication.
  • Power management.
  • Examples of commercial RTOSs.

82
Examples of commercial RTOSs (1)
  • RTOSs VxWorks (VRTX), QNX, LynxOS, eCos,
    DeltaOS, PSX, embOS, ...
  • satisfy the standard Real-Time POSIX 1003.1
    (pre-emptive fixed-priority scheduling,
    synchronization methods, task scheduling
    options).
  • Because people love general-purpose OSs
  • RTLinux (FSMLabs),
  • Linux/RT (TimeSys),
  • Windows CE, ...

83
Examples of commercial RTOSs (2)
  • LynxOS
  • Microkernel architecture that provides
    scheduling, interrupt synchronization support
  • Real-time POSIX support
  • Easy transition from Linux
  • VxWorks
  • Monolithic kernel (reduces run-time overhead, but
    has an increased kernel size compared to
    microkernel designs)
  • Real-time POSIX support
  • Common in industry
  • Mars mission
  • Honda ASIMO robot
  • Switces
  • MRI scanners
  • Car engine control systems

84
Examples of commercial RTOSs (3)
  • RTLinux
  • Dual-kernel approach
  • Makes Linux a low-priority pre-emptable thread
    running on a separate RTLinux kernel
  • Tradeoff between determinism of pure RTOSs and
    flexibility of GPOSs.
  • Periodic tasks only.

85
Open Issues - Multi-criteria Optimization
Problems (1)
  • HW/SW partitioning
  • By evolutionary algorithms genetic algorithms,
    Lothar Thiele, ETH.

86
Open Issues - Multi-criteria Optimization
Problems (2)
  • Configurable processor technology Tensilica
    (http//www.tensilica.com)
  • fitting the processor to the algorithm

87
EU Technological platform ARTEMIS
88
Organization (1)
  • Consultation JSI / room S6D, (01) 4773-363,
    barbara.korousic_at_ijs.si
  • Next lecture 4th March, 2008
  • Web page (course material) csd.ijs.si/korousic/ko
    rousic.html

89
Organization (2)
  • References
  • J. Cooling, Software Engineering for Real-Time
    Systems, Addison-Wesley, 2003
  • F. Vahid, T.Givargis, Embedded System Design A
    Unified Hardware/Software Introduction, Wiley,
    2002
  • IEEE Computer, Vol. 40, No. 10, October 2007
  • http//www.echelon.com/solutions/industrial/appsto
    ries/
  • http//www.mathworks.fr/products/simulink/demos.ht
    ml?file/products/demos/wt/spacecraft.html

90
Organization (3)
  • Course material slide copies, books, papers
  • Exam seminar work OR oral exam
  • May, June, September
About PowerShow.com