Principles and Pragmatics for Embedded Systems

John Regehr

University 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

RAM

1 B 1 KB 1 MB 1 GB

4- and 8-bit

16-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 Introduction

Concurrency Analysis

Real-Time Analysis

Summary 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

Timer

Network

E1 E2 E3

H L

INT

IRQ

Timer

Network 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 Introduction

Concurrency Analysis

Real-Time Analysis

Summary 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 Example

INT

IRQ

Timer

Network Event1

E1 E2E3

Event2

THREAD

H L

H L

An Improvement

INT

IRQ

Timer

Network

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

No

rmal

ized

Su

cces

sfu

l S

ched

ule

s

Alg 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-Task

Default 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.0

012

.50

15.0

017

.50

20.0

0

Task execution time (ms)

Ro

un

d-t

rip

s p

er

se

co

nd

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 Introduction

Concurrency Analysis

Real-Time Analysis

Summary 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/