Principles and Pragmatics for Embedded Systems
John RegehrUniversity of Utah
HierarchicalLoadableSchedulers
Theme: Appropriate, checkable abstractions for systems software
1998 20082003
Secure, large-scale embedded systems?
ComposableExecutionEnvironments
Embedded Systems Account for ~100% of
new microprocessors Consumer electronics Vehicle control systems Medical equipment Smart dust
Embedded Software Goals•Memory•Lock•Time
•Safe•Efficient•Reusable•Easy to develop•Functionally correct
•Minimal•Memory use•CPU use•Power use
•Composable•Late binding
•Debuggable•Testable•Problem specific
Analyses
Time SafetyStack SizeRace DetectionLock Inference…
Optimizations
Thread MinimizationRobust SchedulingLock EliminationInlining…
Binding
CEE – Composable Execution Environments
Infrastructure and metadata
ErrorComposed System
Why CEE? Systems are in the real world
Hard to reach Safety critical
Time is money Space is money Reuse is critical
Within a product line Between generations of products
Embedded Platforms
RAM1 B 1 KB 1 MB 1 GB
4- and 8-bit16-bit
32- and 64-bit
No OS
Real-Time OS (RTOS)GPOS
CPU Type
OS Type
CEE Main Ideas Composition of restricted execution
environments Global analyses and optimizations Late binding of requirements to
implementations
Execution Environment Set of
Idioms and abstractions for structuring software
Rules for sequencing actions Rules for sharing information
Examples Low-level: Cyclic executive, interrupts,
threads, event loop High-level: Dataflow graph, time
triggered system, hierarchical state machines
Bad News Environments have rules Interacting environments have
rules Getting these right is a serious
problem Rules not usually checked
Good News Diversity can be exploited
To create efficient systems To match design problems
Constrained environments are easier to analyze, debug, and understand
Execution Environments
Embedded systems contain multiple execution environments
CEE exploits the benefits of multiple environments while mitigating the problems Local analyses Global analyses
Other Frameworks for Embedded Software
Cadena – Hatcliff et al., Kansas State Koala – Van Ommering, Philips MetaH – Vestal, Honeywell nesC – Gay et al., Intel & Berkeley Ptolemy II – Lee et al., Berkeley Vest – Stankovic et al., Virginia
Motivation and IntroductionConcurrency Analysis
Real-Time AnalysisSummary and Conclusion
Concurrency Embedded systems are
fundamentally concurrent Interrupt-driven Response-time requirements
Concurrency is hard Especially when using components Especially when components span
multiple execution environments
Task Scheduler Logic (TSL) First-order logic with extra
relations and axioms Formalizes locking concerns
across execution environments
TSL Capabilities
Find races and other errors Generate mapping from each
critical section in a system to an appropriate lock Lock inference
Why Infer Locks? Locking rules are hard to learn,
hard to get right Sometimes no lock is needed Components can be agnostic
with respect to execution environments
Global side effects can be managed
TSL Prerequisites
Visible critical sections and resources
Safe approximation of call graph TSL specifications for
schedulers
Using TSL Developers connect components
as usual No direct contact with TSL
Run TSL analysis at build time Success – Return assignment of
lock implementations to critical sections Used to generate code
Failure – Return list of preemption relations that cause races
TSL Concepts Tasks – units of computation Asymmetric preemption
A « B means “B may preempt A” Schedulers
S ◄ B means “S schedules B” Locks
S L means “S provides L” A «L B means “B may preempt A
while A holds L”
Resources and Races Resources
A →L R means “A holds L while accessing R”
Race (A, B, R) = A →L1 R B →L2 R A B A «L1L2 B
Specifying Schedulers
Non-preemptive Generic preemptive Priority
S
A B
(A « B) (B « A)S (t, t0, … , tn) =i. t◄ti
Specifying Schedulers
Non-preemptive Generic preemptive Priority
S
A B
(A « B) (B « A)S (t, t0, … , tn, L) = i. t◄ti
i,j. ti « tj
lL. t l
Specifying Schedulers
Non-preemptive Generic preemptive Priority
S
A B
(A « B) (B « A)S (t, t0, … , tn, L) = i. t◄ti
i,j. i<j ti « tj
lL. t l
H L
INT
IRQ Event
TimerNetwork
E1 E2 E3
H L
INT
IRQ
TimerNetwork Event1
E1 E2E3
Event2
THREAD
H
H
L
L
Applying TSL
Applied to embedded monitoring system with web interface 116 components 1059 functions 5 tasks 2 kinds of locks + null lock
TSL Summary Contributions
Reasoning about concurrency across execution environments
Automated lock inference In ACP4IS 2003 Future work: Optimal lock
inference Minimize run-time overhead Maximize chances of meeting real-
time deadlines
Motivation and IntroductionConcurrency Analysis
Real-Time AnalysisSummary and Conclusion
Real-Time Constraints Examples
Deploy multiple airbags no more than 5 ms after collision
Compute flap position 100 times per second
Real-Time Analysis Output
Success: Static guarantee that deadlines
will be met A schedule (priority assignment)
Failure: List of tasks not guaranteed to
meet deadlines Tasks with hard-wired priorities
do not compose well
Previous ExampleINT
IRQ
TimerNetwork Event1
E1 E2E3
Event2
THREADH L
H L
An ImprovementINT
IRQ
TimerNetwork
E1 E2 E3
V-Sched
H L
Virtual Schedulers Start with collection of real-time
tasks Insert only enough preemption to
permit deadlines to be met Support mutually non-preemptible
collections of tasks Existing real-time theory not
good enough
Background Preemption threshold scheduling
(Saksena and Wang 2000) Supports mixing preemptive and
non-preemptive scheduling But only as a back-end optimization My work: make mixed preemption first-
class
New Abstractions
Task clusters Embed non-
preemptive EEs in a system
Task barriers Respect
architectural constraints
Scheduling Algorithm 1 Target is standard RTOS – no support
for preemption thresholds Three-level algorithm
Outer: iterate over partitions created by task barriers
Middle: iterate over clusters within a partition
Inner: iterate over tasks within a cluster Requires O(n2) priority assignments to
be tested
Scheduling Algorithm 2 Target is RTOS that supports
preemption thresholds More degrees of freedom Known optimal algorithms test O(n!)
priority assignments Use hill-climbing algorithm that
attempts to minimize maximum lateness over all tasks Works well in practice
0
20
40
60
80
100
5 10 15 20 25
Number of Tasks
Nor
mal
ized
Suc
cess
ful
Sche
dule
sAlg 2 Alg 1 Non-Preemptive
Avionics Application
Avionics task set from Tindell et al. (1994) with 17 tasks and two locks Both locks can be eliminated using
task clusters Only 5 threads are needed
Ping / Pong App on Motes
version code data Pin-Int Int-Task Task-TaskDefault 5022 B 232 B 11.3 μs 22.5 μs 16.0 μsCEE 6094 B 448 B 11.3 μs 46.7 μs 45.2 μs
0
5
10
15
20
0.10
1.00
5.00
7.50
10.00
12.50
15.00
17.50
20.00
Task execution time (ms)
Rou
nd-tr
ips
per s
econ
d
DefaultCEE
Real-Time Summary Contributions: Task clusters and
task barriers Better abstractions to protect
developers from multithreading Permit embedding of non-preemptive
execution environments In RTSS 2002
Motivation and IntroductionConcurrency Analysis
Real-Time AnalysisSummary and Conclusion
Status and Ongoing Work Tools exist
Checker for task scheduler logic SPAK – real-time analysis Stacktool – bound stack depth Flatten – parameterizable inlining
Prototype CEE implementations Large systems: PCs with Knit + OSKit Small systems: Motes
Summary CEE is a new framework for
embedded software Exploits qualities of the domain Supports late binding Basis for pluggable analyses and
optimizations Effective compromise between
principles and pragmatics NSF Embedded and Hybrid
Systems 2002–2005
HierarchicalLoadableSchedulers
Theme: Appropriate, checkable abstractions for systems software
1998 20082003
Secure, large-scale embedded systems?
ComposableExecutionEnvironments
Thanks to…
Alastair Reid, Jay Lepreau, Eric Eide, and Kirk Webb
More info and papers here: http://www.cs.utah.edu/~regehr/