Fdp embedded systems

MULTIPLE TASKS
&
MULTIPLE PROCESSES
MULTIRATE SYSTEMS
Dr.G.KAVYA,M.E.,Ph.D
PROFESSOR, DEPT. OF ECE
S.A.ENGINEERING COLLEGE, CHENNAI -77.

Embedded vs. Real Time Systems
• Embedded system: is a computer system that performs a
limited set of specific functions. It often interacts with its
environment.
• RTS: Correctness of the system depends not only on the
logical results, but also on the time in which the results are
produced.
Embedded
Systems
Real Time
Systems
Examples?

Examples
• Real Time Embedded:
– Nuclear reactor control
– Flight control
– Basically any safety critical system
– GPS
– MP3 player
– Mobile phone
• Real Time, but not Embedded:
– Stock trading system
– Skype
– Pandora
• Embedded, but not Real Time:
– Home temperature control
– Sprinkler system
– Washing machine, refrigerator, etc.
– Blood pressure meter

Characteristics of RTS
• Event-driven, reactive.
• High cost of failure.
• Concurrency/multiprogramming.
• Stand-alone/continuous operation.
• Reliability/fault-tolerance requirements.
• Predictable behavior.

Definitions
• Hard real-time — systems where it is absolutely imperative that responses occur
within the required deadline. E.g. Flight control systems.
• Soft real-time — systems where deadlines are important but which will still
function correctly if deadlines are occasionally missed. E.g. Data acquisition
system.
• Real real-time — systems which are hard real-time and which the response times
are very short. E.g. Missile guidance system.
• Firm real-time — systems which are soft real-time but in which there is no benefit
from late delivery of service.
A single system may have all hard, soft and real real-time subsystems.
In reality many systems will have a cost function associated with missing each deadline

Control systems
Example: A simple one-sensor, one-actuator control system.
control-law
computation
A/D
A/D
D/A
sensor plant actuator
rk
yk
y(t) u(t)
uk
reference
input r(t)
The system
being controlled
Outside effects

Control systems cont’d.
Pseudo-code for this system:
set timer to interrupt periodically with period T;
at each timer interrupt do
do analog-to-digital conversion to get y;
compute control output u;
output u and do digital-to-analog conversion;
end do
T is called the sampling period. T is a key design choice. Typical
range for T: seconds to milliseconds.

Tasks and Processes
• A task is a functional description of a connected
set of operations.
• (Task can also mean a collection of processes.)
• A process is a unique execution of a program.
– Several copies of a program may run simultaneously or at different
times.
• A process has its own state:
– registers;
– memory.
• The operating system manages processes.

Why multiple processes?
• Multiple tasks means multiple processes.
• Processes help with timing complexity:
– multiple rates
• multimedia
• automotive
– asynchronous input
• user interfaces
• communication systems

Multi-rate systems
• Tasks may be synchronous or asynchronous.
• Synchronous tasks may recur at different
rates.
• Processes run at different rates based on
computational needs of the tasks.

Example: Engine control
• Tasks:
– spark control
– crankshaft sensing
– fuel/air mixture
– oxygen sensor
– Kalman filter

Typical rates in engine controllers
Variable Full range time (ms) Update period (ms)
Engine spark timing 300 2
Throttle 40 2
Air flow 30 4
Battery voltage 80 4
Fuel flow 250 10
Recycled exhaust gas 500 25
Status switches 100 20
Air temperature Seconds 400
Barometric pressure Seconds 1000
Spark (dwell) 10 1
Fuel adjustment 80 8
Carburetor 500 25
Mode actuators 100 100
© 2008 Wayne Wolf
Overheads for Computers as
Components 2nd ed.

© 2008 Wayne Wolf
Components 2nd ed.
Real-time systems
• Perform a computation to conform to external timing
constraints.
• Deadline frequency:
– Periodic.
– Aperiodic.
• Deadline type:
– Hard: failure to meet deadline causes system failure.
– Soft: failure to meet deadline causes degraded response.
– Firm: late response is useless but some late responses can
be tolerated.

14
Taxonomy of Real-Time Systems

15
Taxonomy: Static
• Task arrival times can be predicted
• Static (compile-time) analysis possible
• Allows good resource usage (low idle time for
processors).

16
Taxonomy: Dynamic
• Arrival times unpredictable
• Static (compile-time) analysis possible only for
simple cases.
• Processor utilization decreases dramatically.
• In many real systems, this is very difficult to
handle.
• Must avoid over-simplifying assumptions
– e.g., assuming that all tasks are independent,
when this is unlikely.

17
Taxonomy: Soft Real-Time
• Allows more slack in the implementation
• Timings may be suboptimal without being
incorrect.
• Problem formulation can be much more
complicated than hard real-time
• Two common and an uncommon way of handling
non-trivial soft real-time system requirements
– Set somewhat loose hard timing constraints
– Informal design and testing
– Formulate as an optimization problem

18
Taxonomy: Hard Real-Time
• Creates difficult problems.
– Some timing constraints are inflexible
• Simplifies problem formulation.

19
Taxonomy: Periodic
• Each task (or group of tasks) executes
repeatedly with a particular period.
• Allows some static analysis techniques to be
used.
• Matches characteristics of many real problems
• It is possible to have tasks with deadlines
smaller, equal to, or greater than their period.
– The later are difficult to handle (i.e., multiple
concurrent task instances occur).

20
Periodic
• Single rate:
– One period in the system
– Simple but inflexible
– Used in implementing a lot of wireless sensor
networks.
• Multi rate:
– Multiple periods
– Should be harmonics to simplify system design

21
Taxonomy: Aperiodic
• Are also called sporadic, asynchronous, or
reactive.
• Creates a dynamic situation
• Bounded arrival time interval are easier to
handle
• Unbounded arrival time intervals are
impossible to handle with resource-
constrained systems.

Example: Adaptive Cruise Control
• Demo video
• Control system
• Hard Real Time
• Multi-rate periodic
• Camera
• GPS
• Low-speed mode for
rush hour traffic
United States Patent 7096109

Data Acquisition and Signal-Processing
Systems
• Examples:
– Video capture.
– Digital filtering.
– Video and voice compression/decompression.
– Radar signal processing.
• Response times range from a few milliseconds to a few
seconds.
• Typically simpler than control systems

Other Real-Time Applications
• Real-time databases.
• Examples: stock market, airline reservations, etc.
• Transactions must complete by deadlines.
• Main dilemma: Transaction scheduling algorithms and real-time
scheduling algorithms often have conflicting goals.
• Data is subject temporal consistency requirements.
• Multimedia.
• Want to process audio and video frames at steady rates.
– TV video rate is 30 frames/sec. HDTV is 60 frames/sec.
– Telephone audio is 16 Kbits/sec. CD audio is 128 Kbits/sec.
• Other requirements: Lip synchronization, low jitter, low end-to-end
response times (if interactive).

Are All Systems Real-Time Systems?
• Question: Is a payroll processing system a real-time system?
– It has a time constraint: Print the pay checks every two weeks.
• Perhaps it is a real-time system in a definitional sense, but it
doesn’t pay us to view it as such.
• We are interested in systems for which it is not a priori
obvious how to meet timing constraints.

The “Window of Scarcity”
• Resources may be categorized as:
– Abundant: Virtually any system design methodology can be used to
realize the timing requirements of the application.
– Insufficient: The application is ahead of the technology curve; no design
methodology can be used to realize the timing requirements of the
application.
– Sufficient but scarce: It is possible to realize the timing requirements of
the application, but careful resource allocation is required.

Example: Interactive/Multimedia
Applications
sufficient
but scarce
resources
abundant
resources
insufficient
resources
Requirements
(performance, scale)
1980 1990 2000
Hardware resources in year X
Remote
Login
Network
File Access
High-quality
Audio
Interactive
Video
The interesting
real-time
applications
are here

OS or not?
Hardware
Operating
System
User Programs
Typical OS Configuration
Hardware
Including Operating
System Components
User Program
Typical Embedded Configuration

© 2000 Morgan
Kaufman
Components
Operating systems
• The operating system controls resources:
– who gets the CPU;
– when I/O takes place;
– how much memory is allocated.
• The most important resource is the CPU itself.
– CPU access controlled by the scheduler.

© 2000 Morgan
Kaufman
Components
Process state
• A process can be in one
of three states:
– executing on the CPU;
– ready to run;
– waiting for data.
executing
ready waiting
gets data
and CPU
needs
data
gets data
needs data
preempted
gets
CPU

© 2000 Morgan
Kaufman
Components
Operating system structure
• OS needs to keep track of:
– process priorities;
– scheduling state;
– process activation record.
• Processes may be created:
– statically before system starts;
– dynamically during execution.

Foreground/Background Systems
• Task-level, interrupt level
• Critical operations must
be performed at the
interrupt level (not good)
• Response time/timing
depends on the entire
loop
• Code change affects
timing
• Simple, low-cost systems

RTS Programming
• Because of the need to respond to timing demands made by different stimuli/responses,
the system architecture must allow for fast switching between stimulus handlers.
• Because of different priorities, unknown ordering and different timing requirements of
different stimuli, a simple sequential loop is not usually adequate.
• Real-time systems are therefore usually designed as cooperating processes with a real-time
kernel controlling these processes.
Concurrent programming

Real Time Java?
• Java supports lightweight concurrency (threads and
synchronized methods) and can be used for some soft
real-time systems.
• Java is not suitable for hard RT programming but real-time
versions of Java are now available that address problems
such as
– Not possible to specify thread execution time;
– Uncontrollable garbage collection;
– Not possible to access system hardware;
– Etc.
– Real-Time Specification for Java
– Sun Java Real-Time System
Requires a Real Time OS underneath (e.g., no Windows support)

Classification of Scheduling Algorithms
All scheduling algorithms
static scheduling
(or offline, or clock driven)
dynamic scheduling
(or online, or priority driven)
static-priority
scheduling
dynamic-priority
scheduling

Scheduling strategies
• Non pre-emptive scheduling
– Once a process has been scheduled for execution, it runs to
completion or until it is blocked for some reason (e.g. waiting for I/O).
• Pre-emptive scheduling
– The execution of an executing processes may be stopped if a higher
priority process requires service.
• Scheduling algorithms
– Round-robin;
– Rate monotonic;
– Shortest deadline first;
– Etc.

Real-time operating systems
• Real-time operating systems are specialised operating systems
which manage the processes in the RTS.
• Responsible for process management and
resource (processor and memory) allocation.
• Do not normally include facilities such as file management.
14

Operating system components
• Real-time clock
– Provides information for process scheduling.
• Interrupt handler
– Manages aperiodic requests for service.
• Scheduler
– Chooses the next process to be run.
• Resource manager
– Allocates memory and processor resources.
• Dispatcher
– Starts process execution.

Interrupt servicing
• Control is transferred automatically to a
pre-determined memory location.
• This location contains an instruction to jump to
an interrupt service routine.
• Further interrupts are disabled, the interrupt
serviced and control returned to the interrupted
process.
• Interrupt service routines MUST be short,
simple and fast.

Metrics for real-time systems differ from that for time-sharing systems.
– schedulability is the ability of tasks to meet all hard deadlines
– latency is the worst-case system response time to events
– stability in overload means the system meets critical deadlines even if all
deadlines cannot be met
What’s Important in Real-Time
Time-Sharing
Systems
Real-Time
Systems
Capacity High throughput Schedulability
Responsiveness Fast average response Ensured worst-case
response
Overload Fairness Stability

© 2008 Wayne Wolf
Components 2nd ed.
Timing specifications on processes
• Release time: time at which process becomes
ready.
• Deadline: time at which process must finish.

© 2008 Wayne Wolf
Components 2nd ed.
Release times and deadlines
time
P1
initiating
event
deadline
aperiodic process
periodic process initiated
at start of period
period
P1P1
deadline
period

Rate requirements on processes
• Period: interval
between process
activations.
• Rate: reciprocal of
period.
• Initiatino rate may be
higher than period---
several copies of
process run at once.
© 2008 Wayne Wolf
Components 2nd ed.
time
P11
P12
P13
P14
CPU 1
CPU 2
CPU 3
CPU 4

© 2000 Morgan
Kaufman
Components
Timing violations
• What happens if a process doesn’t finish by its
deadline?
– Hard deadline: system fails if missed.
– Soft deadline: user may notice, but system doesn’t
necessarily fail.

© 2008 Wayne Wolf
Components 2nd ed.
Example: Space Shuttle software
error
• Space Shuttle’s first launch was delayed by a
software timing error:
– Primary control system PASS and backup system
BFS.
– BFS failed to synchronize with PASS.
– Change to one routine added delay that threw off
start time calculation.
– 1 in 67 chance of timing problem.

Task graphs
• Tasks may have data
dependencies---must
execute in certain order.
• Task graph shows
data/control dependencies
between processes.
• Task: connected set of
processes.
• Task set: One or more tasks.
© 2008 Wayne Wolf
Components 2nd ed.
P3
P1 P2
P4
P5
P6
task 1 task 2
task set

Communication between tasks
• Task graph assumes that all
processes in each task run
at the same rate, tasks do
not communicate.
• In reality, some amount of
inter-task communication is
necessary.
– It’s hard to require immediate
response for multi-rate
communication.
© 2008 Wayne Wolf
Components 2nd ed.
MPEG
system
layer
MPEG
audio
MPEG
video

© 2008 Wayne Wolf
Components 2nd ed.
Process execution characteristics
• Process execution time Ti.
– Execution time in absence of preemption.
– Possible time units: seconds, clock cycles.
– Worst-case, best-case execution time may be useful in
some cases.
• Sources of variation:
– Data dependencies.
– Memory system.
– CPU pipeline.

© 2008 Wayne Wolf
Components 2nd ed.
Utilization
• CPU utilization:
– Fraction of the CPU that is doing useful work.
– Often calculated assuming no scheduling
overhead.
• Utilization:
– U = (CPU time for useful work)/ (total available CPU time)
= [ S t1 ≤ t ≤ t2 T(t) ] / [t2 – t1]
= T/t

© 2008 Wayne Wolf
Components 2nd ed.
State of a process
• A process can be in one
of three states:
– executing on the CPU;
– ready to run;
– waiting for data.
executing
ready waiting
gets data
and CPU
needs
data
gets data
needs data
preempted
gets
CPU

© 2008 Wayne Wolf
Components 2nd ed.
The scheduling problem
• Can we meet all deadlines?
– Must be able to meet deadlines in all cases.
• How much CPU horsepower do we need to
meet our deadlines?

© 2008 Wayne Wolf
Components 2nd ed.
Scheduling feasibility
• Resource constraints
make schedulability
analysis NP-hard.
– Must show that the
deadlines are met for
all timings of resource
requests.
P1 P2
I/O device

© 2008 Wayne Wolf
Components 2nd ed.
Simple processor feasibility
• Assume:
– No resource conflicts.
– Constant process
execution times.
• Require:
– T ≥ Si Ti
– Can’t use more than
100% of the CPU.
T1 T2 T3
T

© 2008 Wayne Wolf
Components 2nd ed.
Hyperperiod
• Hyperperiod: least common multiple (LCM) of
the task periods.
• Must look at the hyperperiod schedule to find
all task interactions.
• Hyperperiod can be very long if task periods
are not chosen carefully.

© 2008 Wayne Wolf
Components 2nd ed.
Hyperperiod example
• Long hyperperiod:
– P1 7 ms.
– P2 11 ms.
– P3 15 ms.
– LCM = 1155 ms.
• Shorter hyperperiod:
– P1 8 ms.
– P2 12 ms.
– P3 16 ms.
– LCM = 96 ms.

© 2004 Wayne Wolf
Components 2nd ed.
Simple processor feasibility example
• P1 period 1 ms, CPU
time 0.1 ms.
time 0.2 ms.
time 0.3 ms.
LCM 5.00E-03
peirod CPU time CPU time/LCM
P1 1.00E-03 1.00E-04 5.00E-04
P2 1.00E-03 2.00E-04 1.00E-03
P3 5.00E-03 3.00E-04 3.00E-04
total CPU/LCM 1.80E-03
utilization 3.60E-01

© 2004 Wayne Wolf
Components 2nd ed.
Cyclostatic/TDMA
• Schedule in time
slots.
– Same process
activation
irrespective of
workload.
• Time slots may be
equal size or
unequal.
T1 T2 T3
P
T1 T2 T3
P

© 2008 Wayne Wolf
Components 2nd ed.
TDMA assumptions
• Schedule based on
least common
multiple (LCM) of
the process periods.
• Trivial scheduler ->
very small
scheduling
overhead.
P1 P1 P1
P2 P2
PLCM

© 2008 Wayne Wolf
Components 2nd ed.
TDMA schedulability
• Always same CPU utilization (assuming
constant process execution times).
• Can’t handle unexpected loads.
– Must schedule a time slot for aperiodic events.

© 2008 Wayne Wolf
Components 2nd ed.
TDMA schedulability example
• TDMA period = 10 ms.
• P1 CPU time 1 ms.
TDMA period 1.00E-02
CPU time
P1 1.00E-03
P2 3.00E-03
P3 2.00E-03
P4 2.00E-03
total 8.00E-03
utilization 8.00E-01

© 2008 Wayne Wolf
Components 2nd ed.
Round-robin
• Schedule process only
if ready.
– Always test processes
in the same order.
• Variations:
– Constant system
period.
– Start round-robin again
after finishing a round.
T1 T2 T3
P
T2 T3
P

© 2008 Wayne Wolf
Components 2nd ed.
Round-robin assumptions
• Schedule based on least common multiple
(LCM) of the process periods.
• Best done with equal time slots for processes.
• Simple scheduler -> low scheduling overhead.
– Can be implemented in hardware.

© 2008 Wayne Wolf
Components 2nd ed.
Round-robin schedulability
• Can bound maximum CPU load.
– May leave unused CPU cycles.
• Can be adapted to handle unexpected load.
– Use time slots at end of period.

© 2008 Wayne Wolf
Components 2nd ed.
Schedulability and overhead
• The scheduling process consumes CPU time.
– Not all CPU time is available for processes.
• Scheduling overhead must be taken into
account for exact schedule.
– May be ignored if it is a small fraction of total
execution time.

© 2008 Wayne Wolf
Components 2nd ed.
Running periodic processes
• Need code to control execution of processes.
• Simplest implementation: process =
subroutine.

while loop implementation
• Simplest
implementation has
one loop.
– No control over
execution timing.
while (TRUE) {
p1();
p2();
}
© 2008 Wayne Wolf
Components 2nd ed.

Timed loop implementation
• Encapuslate set of all
processes in a single
function that
implements the task
set,.
• Use timer to control
execution of the task.
– No control over timing of
individual processes.
void pall(){
p1();
p2();
}
© 2008 Wayne Wolf
Components 2nd ed.

Multiple timers implementation
• Each task has its own
function.
• Each task has its own
timer.
– May not have enough
timers to implement all
the rates.
void pA(){ /* rate A */
p1();
p3();
}
void B(){ /* rate B */
p2();
p4();
p5();
}
© 2008 Wayne Wolf
Components 2nd ed.

Timer + counter implementation
• Use a software count to
divide the timer.
• Only works for clean
multiples of the timer
period.
int p2count = 0;
void pall(){
p1();
if (p2count >= 2) {
p2();
p2count = 0;
}
else p2count++;
p3();
}
© 2008 Wayne Wolf
Components 2nd ed.

Implementing processes
• All of these implementations are inadequate.
• Need better control over timing.
• Need a better mechanism than subroutines.
© 2008 Wayne Wolf
Components 2nd ed.

Fdp embedded systems

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Fdp embedded systems

Similar to Fdp embedded systems (20)

Recently uploaded

Recently uploaded (20)

Fdp embedded systems