Transcript Real-Time Embedded Systems

Real-Time
Embedded Systems
Assist. dr. Barbara Koroušić Seljak
[email protected]
(01) 4773-363
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
Jožef Stefan International Postgraduate School
2
Course synopsis
► Spring
semester:
 Designing and developing embedded systems
 Implementation and performance issues
Jožef Stefan International Postgraduate School
3
Benefits? Learn about ...
► ... challenges and approaches in real-time
embedded system design
► … performance estimation of real-time embedded
systems
► ... current research areas
Jožef Stefan International Postgraduate School
4
Basics of real-time and embedded
systems
1.
Real-time systems
Jožef Stefan International Postgraduate School
5
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
won’t work properly.
Jožef Stefan International Postgraduate School
6
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.
Jožef Stefan International Postgraduate School
7
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 timesliced fashion.
► These
systems are
widely used in
banking, holiday
booking and mail-order
systems.
► Their response time
depends on the
amount of activity.
Jožef Stefan International Postgraduate School
8
Characteristics of a RT system
►A
control computer
detects events
triggered by sensors,
and responds over
actuators within
predefined time
bounds.
Jožef Stefan International Postgraduate School
9
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.
Jožef Stefan International Postgraduate School
10
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
Jožef Stefan International Postgraduate School
11
Hard RT Applications
hard deadline
► Critical
deadlines
► Usually, low SW complexity
► Example: airbag deployment system in
motor vehicles
value
time
fast system – late deployment
defeats the whole purpose of
airbag protection
Jožef Stefan International Postgraduate School
12
Soft RT Applications
soft deadline
value
► Deadlines
are not critical
► Usually, more complex and large SW; manmachine interface
► Examples: factory
automation system,
barcode recognition
system
time
fast/slow system – if fast/slow operator
response is required
Jožef Stefan International Postgraduate School
13
Basics of real-time and embedded
systems
1.
2.
Real-time systems
Embedded systems
Jožef Stefan International Postgraduate School
14
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.
Jožef Stefan International Postgraduate School
15
Characteristics of general-purpose
systems
► Broad
class of applications;
► Programmable by the end user;
► Faster is better.
► Criteria:
 Cost,
 performance (average speed);
personal computers, laptops,
mainframes, servers.
► Examples:
Jožef Stefan International Postgraduate School
16
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
Jožef Stefan International Postgraduate School
17
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 system’s physical
environment;
 Must perform certain tasks in real-time on a physical
platform.
Jožef Stefan International Postgraduate School
18
Examples of ESs in common
environments (1)
Jožef Stefan International Postgraduate School
19
Examples of ESs in common
environments (2)
Jožef Stefan International Postgraduate School
20
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)
►
Jožef Stefan International Postgraduate School
21
Microprocessor and semiconductor
chips’ trends
Jožef Stefan International Postgraduate School
22
Brief history of ESs (1)
►
Late 1940’s: MIT Whirlwind
computer was designed for realtime operations:
 Originally designed to control
an aircraft simulator;
►
Whirlwind computer
Apollo Guidance
computer
In the 1960’s:
 The first recognizably ES was
the Apollo Guidance Computer
(MIT Instrumentation
Laboratory);
►
By the end of the 80’s:
 ESs were the norm rather than
the exception for almost all
electronics devices
(microcontrollers, I2C).
Intel 4004
Jožef Stefan International Postgraduate School
23
Brief history of ESs (2)
Today’s complex ESs are based on networks of
distributed microprocessors that run many off-theshelf 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.
Jožef Stefan International Postgraduate School
24
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.
Jožef Stefan International Postgraduate School
25
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.
Jožef Stefan International Postgraduate School
26
Students
Student
1.
2.
3.
4.
5.
6.
7.
Student
Student
Student
Student
Student
Student
Student
Research area
1
2
3
4
5
6
7
Jožef Stefan International Postgraduate School
27
ESs’ modeling
►
Challenges:
1. Technological: build an embedded system of
predictable functionality and quality
(performance & robustness) considering the
system’s constraints;
Jožef Stefan International Postgraduate School
28
How to satisfy the technological
challenge?
Execution constraints
CPU speed
memory
power
HW failure rates
Computing
methods
algorithms
reuse
System’s reaction
constraints
performance (deadlines, jitter, throughput)
robustness (security, safety, availability)
Jožef Stefan International Postgraduate School
29
Hardware design?
new computer
architectures (open & flexible multi-core SoC)
Execution constraints
CPU speed
memory
power
HW failure rates
Computing
methods
algorithms
reuse
System’s reaction
constraints
performance (deadlines, jitter, throughput)
robustness (security, safety, availability)
Jožef Stefan International Postgraduate School
30
Software design?
Execution constraints
CPU speed
memory
power
HW failure rates
new software
architectures
(1-2 million lines of code)
Computing
methods
algorithms
reuse
System’s reaction
constraints
performance (deadlines, jitter, throughput)
robustness (security, safety, availability)
Jožef Stefan International Postgraduate School
31
Control design?
Execution constraints
CPU speed
memory
power
HW failure rates
System’s reaction
constraints
Computing
methods
algorithms
reuse
novel system-level analysis,
modeling methods and tools
performance (deadlines, jitter, throughput)
robustness (security, safety, availability)
Jožef Stefan International Postgraduate School
32
HW/SW Codesign!
Execution constraints
Design, validation & maintenance processes
need to support the high-performance
HW & communication technologies!
CPU speed
memory
power
HW failure rates
Computing
methods
algorithms
reuse
System’s reaction
constraints
performance (deadlines, jitter, throughput)
robustness (security, safety, availability)
Jožef Stefan International Postgraduate School
33
HW/SW Co-design Approach
►
►
Co-specification
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.
Problem analysis
Requirement specifications
HW/SW partitioning
Co-synthesis
Interface
SW
C
code
SystemC code
System Integration
Jožef Stefan International Postgraduate School
HW
VHDL
code
Co-simulation
Co-verification
34
The Co-design Ladder
(Vahid&Givargis, 2002)
SW
Sequential program codes (e.g., C, VHDL, SystemC)
Compilers
(1960s,1970s)
Behavioral synthesis
(1990s, 2000s)
Register transfers
Assembly instructions
Assemblers, linkers
(1950s, 1960s)
RT synthesis
(1980s, 1990s)
Logic equations/FSMs
Logic synthesis
(1970s, 1980s)
Machine instructions
HW
Traditional program on a programmable
processor
Logic gates
VLSI, ASIC, or PLD
implementation
Jožef Stefan International Postgraduate School
35
Embedded Systems Design
Challenge
► Design
goal:
 Construct a system with desired functionality.
► Key
design challenge:
 Simultaneously optimize numerous design
metrics:
►Time-to-prototype
8 months
►Time-to-market
►Maintainability
►Correctness,
reliability, safety, etc.
Jožef Stefan International Postgraduate School
36
ESs’ modeling
►
Challenges:
1. Technological: build an embedded system of
predictable functionality and quality
(performance & robustness) considering the
system’s constraints;
2. Scientific: integrate Electrical Engineering and
Computer Science methodologies.
Jožef Stefan International Postgraduate School
37
How to satisfy the scientific
challenge?
Electrical engineering
Computer science
►
►
Differential equations
Linear algebra
Probability theory
►
Sythesis
►
►
►
►
►
►
►
►
Theories of estimation
Theories of robustness
Logic
Discrete structures
Automata theory
Theories of correctness
Verification
Let’s take down the cultural wall between
the two fields!
Jožef Stefan International Postgraduate School
38
Modeling (1)
Main steps of the ES’s design:
1.
2.
3.
Definition of system’s constraints /
requirements;
Derivation of an abstract system, i.e. a
model;
Automatic generation of a system.
Jožef Stefan International Postgraduate School
39
Modeling (2)
HW design
SW design
model
a HW description
model
a program
a computer-aided design tool
synthesizes
a circuit
a compiler
generates
a code
► However,
we cannot separate computation (SW)
from physicality (platform & environment)!
Jožef Stefan International Postgraduate School
40
Analytical modeling (1)
► Analytical
model is a simulation, based on
an abstract system’s representation, which:
 attempts to find analytical (equation-based)
solutions to problems that enable the prediction
of the system’s behavior from a set of
parameters and initial conditions.
Jožef Stefan International Postgraduate School
41
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 (modelbased);
►ANSYS.
Jožef Stefan International Postgraduate School
42
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 system’s structure.
Jožef Stefan International Postgraduate School
43
Analytical modeling (4)
► Embedded
MATLAB:
 automatic
code
generation of
C and C++
objects,
optimized for
ESs.
Jožef Stefan International Postgraduate School
44
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.
Jožef Stefan International Postgraduate School
45
Computational modeling (2)
► Types
of computational models :
 machine-based (RT/UML, AADL)
►object-oriented,
►dynamic
simulation,
►more generic (execution semantics independent) –
model-based.
Jožef Stefan International Postgraduate School
46
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.
Jožef Stefan International Postgraduate School
47
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.
Jožef Stefan International Postgraduate School
48
Analytical vs. computational
modeling
Analytical modeling
Concurrency
Computational modeling
+ / naturally deals with
concurrency
-
+
-
- / struggles with partial &
incremental specifications
+ / supports nondeterministic
abstraction hierarchies
Computational
complexity
-
+ / rich theory
Analytical & synthesis
techniques
+
-
Automatic generation
of a system
+
+ / directly executable models
Physical constraints
Nondeterminism
Jožef Stefan International Postgraduate School
49
Software and program design
concepts
► SW
Prototyping
Jožef Stefan International Postgraduate School
50
What do we want in our SW?
►
 the static property that a
program is consistent with
its specification;
dependable SW
is
►
correct
Correctness:
 the extend to which a
program can be expected to
perform its intended function
with required precision;
safe
reliable
►
We wish that our SW is
dependable, is delivered on
time and is done within
budget!
Reliability:
Safety:
 the extend to which a
program is concerned with
the consequences of failure.
Jožef Stefan International Postgraduate School
51
How to achieve this? (1)
Develop a clear statement of system’s requirements.
2. Ensure that the design solution is capable of achieving this.
3. Organize the development so that the project is manageable.
4. Organize the development so that timescales can be met.
5. Make sure that the design can be managed without major
rewrites.
6. Design for testability.
7. Minimize risks by using tried and trusted methods.
8. Ensure that safety is given its correct priority.
9. Make sure that the project doesn’t completely rely on
particular individual.
10. Produce a maintainable design.
11. ?
1.
Jožef Stefan International Postgraduate School
52
How to achieve this? (2)
System’s requirements
functional
non-functional
non-functional
non-functional
What it’s
supposed to do
How well it
must do it
How it fits in
with its
environment
Do’s and
don’t’s
function
performance
interfaces
constraints
‘real-world’ interfaces
man-machine
plant
‘SW world’ interfaces
OSs
Jožef Stefan International Postgraduate School
databases
53
How to achieve this? (3)
sy stem’s
requirements
capturing
virtual prototyping
design
architectural
design
architectural
ev aluation
integration
architectural
ref inement
hardware
libraries
sof tware
libraries
sy nthesis
metrics
collection
sof tware
hardware
Jožef Stefan International Postgraduate School
54
OSs for RT Applications
► Basics
of RTOSs;
Jožef Stefan International Postgraduate School
55
Role of OSs
►
Typical OS configuration:
User programs
OS
►
Typical embedded
configuration:
User programs
including RTOS
components
HW
HW
►
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.
Jožef Stefan International Postgraduate School
56
OS hierarchy
►
Typical OS configuration:
Application
program
Application
program
►
Application
program
Typical embedded
configuration:
Application
program interfaces
OS Executive
OS User Interface Shell
OS Kernel
HW
File & Disk Control
OS Kernel
Real-world
interfaces
►
HW
►
OS kernel gives us control over the
resources:


No background processes;
Bounded number of tasks;


Manipulation of task priorities;
Choice of scheduling options.
OS kernel gives us control over
timing by allowing:
Jožef Stefan International Postgraduate School
57
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 task with a real-time
purpose
loop
A function is a procedure
that is called. It runs, then
exits and may return a
value.
Jožef Stefan International Postgraduate School
while(1)
{
get_data();
process_data();
}
functions
58
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 patient’s
condition.
►
Sporadic Tasks:
 Aperiodic tasks with known minimum inter-arrival time (Ti, Ci).
Jožef Stefan International Postgraduate School
59
Terminology: tasks & functions (3)
► Task’s
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.
Jožef Stefan International Postgraduate School
60
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.
Jožef Stefan International Postgraduate School
61
Basic RTOS kernel functions
► Task
scheduler: to determine which task will
run next in a multitasking system;
► Task dispatcher: to perform necessary bookkeeping to start a task;
► Control of shared resources: to support
intertask communication.
Jožef Stefan International Postgraduate School
62
OSs for RT Applications
► Basics
of RTOSs;
► Scheduling modeling assumptions.
Jožef Stefan International Postgraduate School
63
RTOS kernel design strategies (1)
Simple options:
1. Pooled loop systems:
►



2.
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.
Jožef Stefan International Postgraduate School
64
Interrupt handling
►
An interrupt is a SW or HW
signal to the processor,
interrupts
 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;
ISR
ISR
 Interrupts can be:
► prioritized,
► disabled,
► masked.
ISR
Processor must check for
interrupts very frequently.
Jožef Stefan International Postgraduate School
65
RTOS kernel design strategies (2)
►
1.
2.
3.
Extended options:
Multitasking
Foreground / background systems
Full featured RTOSs
Jožef Stefan International Postgraduate School
66
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.
Jožef Stefan International Postgraduate School
67
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
Jožef Stefan International Postgraduate School
68
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: P=1/ 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. noninteracting.
►
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).
Jožef Stefan International Postgraduate School
69
Rate Monotonic systems (2)
task
execution
time (ms)
deadline /
period (ms)
1
1
8
2
2
5
3
2
10
Ut=1/8+2/5+2/10=0.725
U= 3(21/3-1)=0.78
Since Ut < U ... the system is
schedulable!
► Utilization:
 The percentage of
available processor
time spent
executing tasks (Ut);
 The lowest
utilization figure U
for n tasks is
U=n(21/n-1).
Jožef Stefan International Postgraduate School
70
Earliest Deadline First (EDF)
► General
characteristics:
 Priority-based preemptive dynamic
scheduling;
 Highest-priority ready
task runs first;
 Task priority P is set
according to its due
time Tg: P=1/ 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.
Jožef Stefan International Postgraduate School
71
Foreground / background systems
► Most
common hybrid solution for embedded
applications.
► Involve interrupt-driven (foreground) & noninterrupt-driven (background) processes:
 Anything non-time-critical should be in
background.
Jožef Stefan International Postgraduate School
72
OSs for RT Applications
► Basics
of RTOSs;
► Scheduling modeling assumptions;
► Interprocess communication.
Jožef Stefan International Postgraduate School
73
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).
Jožef Stefan International Postgraduate School
74
How to overcome priority inversion?
►
Problem:
►
T1 is blocked because T3
has the resource
priority
T1
T1
high
Solution (priority
ceiling protocol):
T3 inherits T1’s priority
so it can finish and then
T1 can have the resource
priority
T1 T3
high
T2
low
T3
T3
T1
T2
T3
low
T3
time
T3
time
T2 can block T3, which
also keeps T1 waiting
Jožef Stefan International Postgraduate School
75
OSs for RT Applications
► Basics
of RTOSs.
► Scheduling modeling assumptions.
► Interprocess communication.
► Power management.
Jožef Stefan International Postgraduate School
76
Power optimization
► Power
management:
 determines how system resources are going to
be used to satisfy the power consumption’s
requirement.
► RTOS
units:
may reduce power by shutting down
 Entering and leaving the power-down mode
requires both, energy and time.
Jožef Stefan International Postgraduate School
77
Power management policies (1)
► Request-driven:
► Predictive
 Power up once request
is received;
 Con: Adds delay to
response.
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.
Jožef Stefan International Postgraduate School
78
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.
Jožef Stefan International Postgraduate School
79
Advanced Configuration and
Power Interface
► ACPI
(open standard for power
management services).
application
device
drivers
RTOS kernel
power
management
ACPI BIOS
Hardware platform
Jožef Stefan International Postgraduate School
80
OSs for RT Applications
► Basics
of RTOSs.
► Scheduling modeling assumptions.
► Interprocess communication.
► Power management.
► Examples of commercial RTOSs.
Jožef Stefan International Postgraduate School
81
Examples of commercial RTOSs (1)
► RTOSs:
VxWorks (VRTX), QNX, LynxOS, eCos,
DeltaOS, PSX, embOS, ...
 satisfy the standard Real-Time POSIX 1003.1 (preemptive fixed-priority scheduling, synchronization
methods, task scheduling options).
► Because
people love general-purpose OSs:
 RTLinux (FSMLabs),
 Linux/RT (TimeSys),
 Windows CE, ...
Jožef Stefan International Postgraduate School
82
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
Jožef Stefan International Postgraduate School
83
Examples of commercial RTOSs (3)
► RTLinux:
 Dual-kernel approach:
► Makes
Linux a lowpriority pre-emptable
thread running on a
separate RTLinux kernel;
► Tradeoff between
determinism of pure
RTOSs and flexibility of
GPOSs.
 Periodic tasks only.
Jožef Stefan International Postgraduate School
84
Open Issues - Multi-criteria
Optimization Problems (1)
► HW/SW
partitioning:
 By evolutionary
algorithms & genetic
algorithms, Lothar
Thiele, ETH.
Jožef Stefan International Postgraduate School
85
Open Issues - Multi-criteria
Optimization Problems (2)
► Configurable
processor
technology Tensilica
(http://www.tensilica.com):
 fitting the processor
to the algorithm;
Jožef Stefan International Postgraduate School
86
EU Technological platform ARTEMIS
Jožef Stefan International Postgraduate School
87
Organization (1)
► Consultation:
JSI / room S6D, (01) 4773363, [email protected]
► Next lecture: 4th March, 2008
► Web page (course material):
csd.ijs.si/korousic/korousic.html
Jožef Stefan International Postgraduate School
88
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/appstories/
 http://www.mathworks.fr/products/simulink/demos.html
?file=/products/demos/wt/spacecraft.html
Jožef Stefan International Postgraduate School
89
Organization (3)
► Course
material: slide copies, books, papers
► Exam: seminar work OR oral exam
 May, June, September
Jožef Stefan International Postgraduate School
90